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

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


/ Pexels / Caio / CC

Чем грозит слабый SSH-key-менеджмент?

SSH-ключи задуманы в качестве упрощенного способа входа на сервер без необходимости ввода пароля. Как рассказывает Тату Улёнен (Tatu Ylonen), создатель SSH и генеральный директор компании SSH Communications Security, специализирующейся на корпоративной защите, на одном сервере накапливаются от 50 до 200 ключей. В случае с крупными предприятиями их количество исчисляется сотнями тысяч, а иногда — миллионами.

Как правило, их создают разработчики и администраторы баз данных, чтобы упростить аутентификацию. В итоге, по словам Тату, около 90% ключей, созданных за годы, а порой и за десятилетия, не используются, но остаются активными. Более того, около 10% этих ключей предоставляют root-доступ. Что это означает для злоумышленников? В их распоряжении оказывается безграничное поле для маневров.

Опрос Ponemon Institute, проведенный в 2014 году среди 2,1 тыс. системных администраторов из числа компаний Global 2000, показал, что три из четырех предприятий уязвимы для атак из-за слабой защиты ключей для SSH.

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

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

В контексте IoT есть и более серьезная опасность: SSH-ключи могут открыть доступ к аппаратным средствам. Тату Улёнен рассказал, что производители все чаще стремятся оптимизировать процесс и прибегают к удаленным технологиям управления, полагаясь на защищенность сетевого протокола. Тем временем ключевые файлы SSH продаются на «черных рынках», и с помощью них конкуренты могут получить доступ к камерам наблюдения или вызвать сбой в системе защиты компании. Сценариев атак достаточно много, а последствия их непредсказуемы.

«Для исправления этого нет универсального решения. Это даже не техническая проблема — это проблема управления», — утверждает Тату.

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

Как выстроить управление SSH-ключами на предприятии

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

Некоторые предприятия используют Excel для учета. Системы управления ключами на основе бумажных или электронных таблиц используются 57% компаний, согласно исследованию Global Encryption Trend Study от 2016 года. Однако, как отмечает специалист в области кибер-безопасности Майкл Кобб (Michael Cobb), такой подход подвержен ошибкам, оттого не может быть эффективным.

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

Что касается автоматизации, Тату Улёнен приводит пример одного из трех крупнейших банков в США, в штате которого насчитывалось 200 системных администраторов. 10% команды занималась исключительно SSH-ключами. Кроме нерационального использования ресурсов, в такой ситуации повышается риск, связанный с человеческим фактором. Например, возможность случайного присвоения ключу root-доступа.

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

Компаниям стоит адаптировать процессы по автоматизированному удалению ключей с уходом людей, которым они принадлежали. В то же время некоторыми компаниями активно используется метод учета ключей с момента запуска сервера. Так, 1cloud предоставляет доступ к панели управления, где в удобной форме хранятся все ключи, причем генерация секретных ключей осуществляется администратором самостоятельно, что гарантирует дополнительную безопасность. А о том, как подключиться к Linux-серверам, используя SSH-ключи, мы подготовили небольшое руководство.

Мэттью Маккенна (Matthew McKenna), коммерческий директор SSH Communications Security, советует сосредоточиться на том, какие ключи могут иметь root-доступ и насколько серьезными будут последствия утраты контроля над каждым из таких ключей. Поэтому следующий шаг — четкое распределение ответственности в сети с установлением каждого владельца ключа. Использование надежных криптографических стандартов и передовой практики в этой области — еще один гарант безопасности для организации.

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


/ Pixabay / Ashish_Choudhary / CC

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

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

Инструменты для управления SSH-ключами

Так как создатель SSH выступает за автоматизацию работы с ключами, и SSH Communications Security активно разрабатывает соответствующие продукты, мы собрали несколько полезных инструментов для key-менеджмента.

• PuTTY: клиент SSH, разработанный для платформы Windows. Он является программным обеспечением с открытым исходным кодом и позволяет генерировать новые ключи.
• Thycotic Secret Server: управление привилегированными пользователями. Позволяет связать генераторы ключей SSH с официальной системой управления учетными данными.
• Universal SSH Key Manager: разработка SSH Communications Security, которая предлагает комплексное управление ключами, в том числе полный учет и контроль доступа SSH, криптографические рекомендации и управление конфигурацией, непрерывный мониторинг, блокировку доступа в случае необходимости, восстановление и управление жизненным циклом ключей.
• PowerBroker Password Safe: инструмент для распределения прав в сети. Решение позволяет управлять паролями и сеансами, обеспечивая безопасный контроль доступа. Инструмент способен выборочно обрабатывать изменения паролей, проводить их проверку для определенных рабочих групп, поддерживать стандартные алгоритмы шифрования, такие как AES 256 и Triple DES, осуществлять автоматическую ротацию ключей и автоматически обновлять пароли на удаленных и мобильных устройствах.
• Venafi TrustAuthority: пригодится при развертывании сертификационного центра. Он способен обнаруживать внутренние сертификаты путем сканирования локальных систем и хранить ключи SSH для пользователей и хостов.
• GitWarden: инструмент для GitHub-команд, предоставляющий автоматическую синхронизацию локальных учетных записей пользователей, ключей SSH с командами организации. Это упрощает управление пользователями напрямую через пользовательский интерфейс GitHub.

Обсуждая лучшие способы управления SSH-ключами, ряд пользователей Hacker News отдали предпочтение физической защите, девайсам, которые обеспечивают аутентификацию при непосредственном контакте. Такие решения, как YubiKey 4 зачастую используются для двухфакторной аутентификации с соблюдением виртуальных мер безопасности.

P.S. Еще несколько материалов из нашего блога на Хабре:

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

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

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

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

Поддерживающие сообщества

Понятное дело, что далеко не каждая компания отважится пойти против патентного тролля. Как же увеличить шансы малых предприятий в борьбе против троллей? Для этого были созданы разные сообщества, например PatentShield, LOT Network, The Law School Patent Troll Defense Network и другие.



Разработчики и малые предприятия получили возможность бесплатно воспользоваться услугами юридических вузов и юристов, которые участвуют в The Law School Patent Troll Defense Network. Для этого необходимо отправить запрос на сайте сообщества, описывая деятельность компании и сложившуюся ситуацию. Сообщество было сформировано и управляется на сегодняшний день объединением разработчиков приложений (Application Developers Alliance). Помощь малым предприятиям обойти ситуацию выплаты лицензионных отчислений патентным троллям способствует более глобальной цели, а именно сделать патентный троллинг менее прибыльным и вследствие заставить инвесторов отказаться от финансирования троллей.

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



Интересным фактом является то, что Google является так же членом и другой сети по борьбе с патентными троллями: LOT (License on Transfer) Network. Принцип работы данной сети отличается и состоит в предотвращении возможных нападок. А именно при вступлении в сообщество подписывается соглашение и если патенты одного из членов сообщества попадают тем или иным способом патентному троллю, то остальные участники будут иметь автоматическое лицензирование данных патентов. Это означает, что они не смогут быть применены в суде против компаний подписавших соглашение. Лицензирование вступает в силу только в случае передачи ИС патентному троллю (обозначенных в соглашении как Patent Assertion Entity). Членство в таком сообществе тоже требует определенных затрат, однако не для стартапов с годовым оборотом менее $5 миллионов – для них вступление в сообщество является бесплатным.

Регулирование на законодательном уровне

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

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

Организация Electronic Frontier Foundation (EFF – лидирующая некоммерческая организация в США защищающая гражданские свободы в цифровом мире) выступает за следующие меры для обеспечения надлежащего законодательного регулирования:

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



Пересмотр законности патента – согласно секции 18 American Invents Act, каждый, кому угрожают иском, может попросить пересмотр законности патентов определенных категорий у патентного ведомства. Однако это не распространяется на патенты о программном обеспечении, а так же является временным пунктом, а именно до 2020 года.

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

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

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

С того времени, как Google сделал Koltin новой любимой женой уже прошло достаточно времени. И сразу же после этого объявления наша команда начала новый проект полностью на Котлине. Проясню: не тестовый или просто внутренний проект, а новый модуль для живого приложения с 600+ тысячами активных пользователей в месяц. Какой опыт мы из этого извлекли? Что мы выиграли и что потеряли?

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

Фан-фактор

Очевидно, Котлин надо сначала выучить. Даже несмотря на то, что кривая обучения не выглядит как гора К2, плоской она тоже не является: один из коллег заметил, что на выполнение задач на Котлине у него уходило примерно в два раза больше времени, тем не менее, никто ни разу не пожаловался. Наоборот, все были только рады возможности применить новую крутую игрушку со всеми ее свистелками в продакшене. Более того, для привлечения лучших кандидатов мы стали не сговариваясь упоминать в ходе интервью, что пишем на Котлине. Так что чистая победа в этой категории +100 очков Котлину.

Скорость

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

Скорость написания

В среднем на то, чтобы почувствовать себя более-менее комфортно с Котлином ушло около двух недель. И еще примерно две недели понадобилось, чтобы начать писать на нем быстрее чем на Джаве. Тем, у кого был опыт Scala и Groovy было проще, так как авторы Котлина во многом вдохновлялись ими. Поддержка со стороны IDE все еще не идеальна: много удобных и привычных по Джаве рефакторингов и автоподстановок просто не работают сейчас. Но даже несмотря на эту проблему, в итоге мы все равно немного в плюсе по скорости. Слабая победа Котлина в этой категории, впрочем мы ждем большего от финальной версии Android Studio 3.0 (на момент написания статьи мы все еще пользовались бетой).

Скорость чтения

Хоть код на Котлине и получается ощутимо короче, разбирать пулл-реквесты на ГитХабе приходится дольше. Почему так? Во-первых, ни Google ни JetBrains не подготовили полноценный стайл-гайд, так что члены команды стали проводить больше времени за дискуссиями на тему «красоты». Даже официальные примера кода не во всем однородны. Во-вторых, некоторые новые (для Джавы) конструкции могут быть использованы во вред, в то время как на Джаве так написать попросту не получится. Итого: небольшой но все же проигрыш на этом направлении, хотя, опять же, мы ожидаем улучшений в ближайшем будущем, потому что по поводу 99% спорных кейсов уже пришли к согласию.

Инструменты и библиотеки

Страшная правда в том, что Checkstyle и Lint пока еще абсолютно бесполезны для Котлина, а мы их используем и активно, но тот же Dagger работает отлично. А еще мы получили Kotlin-X и собираемся втянуть в проект Anko. Тут опять проигрыш Котлина, и хоть Anko с Kotlin-X могут подсластить пилюлю, мы особо не ожидаем драматических улучшений в работе стайлчекеров в ближайшее время.

Тестирование

А вот тут мы неожиданно получили преимущество. С Котлином не поставляется никаких новых инструментов или библиотек для тестирования, но новые языковые фичи, особенно type inference, extensions, и reified-типы существенно сократили количество бойлерплейта в тестовых классах. Чистая победа тут, даже несмотря на то, что IDE иногда пытается запустить Espresso как будто это чистые JVM юнит-тесты и, очевидно, не справляется с задачей.

Саморазвитие

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

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

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

Мы поддерживаем офис одной сервисной компании и хотели бы немного рассказать про нашу работу. Для поднятия настроения, так сказать. В общем-то, наш день выглядит одинаково: приходим, логинимся в cisco agent, садимся за телефон и начинаем слушать хотелки юзеров. Что-то разруливаем сами, что-то передаём второй линии рядом. Несмотря на то, что офис заказчика состоит преимущественно из инженеров, тикеты не очень сильно отличаются от тикетов нефтегазовой компании или госкомпании. Конечно, без того, чтобы проехать 200 километров, чтобы включить принтер в розетку (реальный случай), но всё же.

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

Разумеется, техэксперты и техмены, обитающие в офисе, по большинству решают проблемы самостоятельно (ну или ставят очень понятные тикеты, где всё делается в пару кликов). Но есть ещё и различные «дополнительные службы», типа: столовая или спортзал. Некоторые из них вообще иногда доставляют нам море радости своими тикетами с просьбой установить World of Tanks на компьютер. Или: «Я слышу людей в мониторе, а меня никто не слышит!»

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

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

Естественно, всем всё нужно вчера — но это, думаю, данность у каждой первой линии.

Иногда бывают дни ада — это когда у пользователей приходит время плановой смены паролей. За такой день может поступить 70–80 звонков на сотрудника: всем нужно войти в учётки. Это ещё не считая обычных проблем вроде кончившегося тонера или сломавшегося блока питания.

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

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

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

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

Один раз девушку из бухгалтерии безопасники до того запугали, что она писала специальный тикет, чтобы мы подвинули монитор на столе на 11 сантиметров влево. Кстати, с мониторами частый вопрос от бухгалтерии при замене — это сохранятся ли ярлыки. Успокаиваем. Сохранятся.

Один раз просили включить Sony PlayStation4, причём в рамках поддерживаемого сервиса. Смотрим — он и правда поддерживаемый, теперь в комнате отдыха одна стоит.

Постоянно к нам стучат люди, которые застряли где-то в лифте (необязательно в офисе), когда есть проблемы с кондиционерами. Был однажды тикет «у нас тут репетиция в спортзале — нужны парни потанцевать».

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

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

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

Есть пользователь-вампир: он уже 6 лет пишет заявки только после заката. Мы его не знаем, но тикеты закрываем. Наверное, какой-нибудь спец по поддержке линий связи Дальнего Востока. Кстати, да, для ночной смены самое интересное время — 4–5 часов утра, когда просыпается Иркутск и начинает ставить срочные задачи.

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

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

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

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

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



Сразу к делу — вот о чём написано в этой статье:

• Материалы для производства печатных плат
• Учет изменения толщины препрега в процессе изготовления PCB
• Учет Etch Factor
• Особенности расчета толщины металлизации
• Учет паяльной маски

Все описанное ниже — это не Know How, а по сути, собранные воедино и систематизированные данные из разных источников. На абсолютное знание мы также не претендуем.
Итак, поехали.

Материалы для производства печатных плат

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

• Итоговое изделие отличается от того, что описано в вашей КД (иногда чуть более, чем полностью).
• Повторяемости результата при переходе к другому производителю — нет. Например у нас есть борд, который запускался на двух разных фабах с совершенно разными стеками (при этом исходные данные в обоих случая были одни и те же).
• Если толщины проводников на печатной плате находятся в зоне 4 mil — то любое изменение их ширины в сторону уменьшения весьма серьезно влияет на потери. Если между проводником 6 mil и 5 mil разница незначительна, то между 5 mil и 4 mil — весьма существенна, а 4 mil и 3 mil — это с точки зрения потерь разные вселенные. (Вообще на наш взгляд идеальные топологии дифференциальной пары — 6-6-6 или 7-7-7).

Поэтому мы предпочитаем сформировать стек так, чтобы его зависимость от особенностей конкретного производителя PCB сводилась к минимуму. Если вы работаете с одним и тем же вендором, то вполне реально сформировать стек так, чтобы его модификация производителем не требовалась совсем. Это экономия 1—2 недель при подготовке к производству.

Кстати оффтоп.
Наверняка кто-то нибудь захочет спросить — что лучше, сильносвязанные или слабосвязанные дифференциальные пары. Наше мнение: лучше слабосвязанные — их проще выровнять по длине. Можно позволить себе более серьезные бампы. Никаких особенных преимуществ сильносвязанных пар перед слабосвязанными (если не рассматривать странные топологии типа 5-14-5) c точки зрения SI на наш взгляд — нет. Для любителей формальных правил: одна-две ширины между проводниками в паре — нормально. Больше — уже не очень. Меньше — трудно выравнивать. Несмотря на то, что ЭМС показатели сильносвязанных пар сильно лучше, в абсолютном выражении это «сильно» — несущественно.

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


Толщины разных типов препрегов — как правило одни и те же у разных производителей. Поэтому информация на приведенной картинке — актуальна и юзабельна безотносительно к производителю материала (Dk/Df, понятно, у всех разные).

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

Если значения Dk/Df приведены для разных частот, то рекомендуется использовать значения данных параметров для частоты, наиболее близкой к частоте Найквиста наиболее быстрого интерфейса на PCB. Например, если в PCB присутствует PCI Express Gen3, то следует использовать значения Dk/Df для частоты, наиболее близкой к 4 ГГц.

Кто-то возразит: как же, ведь полоса того же Gen3 простирается аж до 18 ГГц. Это правда — но спецификация PCIe регламентирует RL и IL до Найквиста, да и не пройдут все эти адовые гигагерцы через коннекторы, переходные отверстия и печатную плату — затухнут по дороге. А если пройдут — это большой вопрос, понравится ли Вам результат.

В ситуации, когда на PCB присутствует несколько разных высокоскоростных интерфейсов — не стоит в рамках стека одной платы использовать значения Dk/Df для разных частот. Несмотря на то, что такой подход является более верным с точки зрения расчета импеданса — он вызовет большие трудности при согласовании стека с производителем PCB (их тестовое оборудование настраивается на одну конкретную частоту).

В случае, если значения Dk/Df значительно варьируются с частотой, а контроль импеданса критичен — имеет смысл, получив значения импеданса для реальной частоты интерфейса, пересчитать его, взяв Dk для некоторой единой частоты (самого критичного интерфейса). «Отнормированное» таким образом значение импеданса — указать в качестве целевого для контроля производителем PCB.

Например вы делаете расчет 100 Омной трассы для частоты 4 ГГц, используете значение Dk для 4 ГГц, и в соответствии с полученными данными осуществляете трассировку. Далее, если у вас например есть интерфейсы, требующие расчета для 10 ГГц — подставьте значение Dk для более высокой частоты в исходный расчет. Допустим, при этом вы получите значение импеданса 105 Ом. Наш совет: вот 105 Ом и укажите производителю PCB для контроля. Не стоить морочить ему голову разными Dk для разных частот на одном и том же слое.

Также не повредит на берегу поинтересоваться с каким стеклом работает фаб, чтобы не было потом проблем со сроками поставки. Потому что есть популярные препреги и не очень. Обычно на складе у него всегда в достатке 3-4 типа, из которых и стоит выстраивать стек PCB. Материалов с низкими потерями обычно на складе не бывает, в силу ограниченного срока хранения — поэтому применение чего-то особенного это всегда вопрос не столько цены, сколько сроков изготовления.

Учет изменения толщины препрега в процессе изготовления PCB

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

Условия	Изменение толщины препрега при начальном значении
	Не более 2.3 mil	Более 2.3 mil
Прилегание к меди 0.5 oz с 30% заполнением	0.4 mil	0.4 mil
Прилегание к меди 0.5 oz с 70% заполнением	0.1 mil	0.2 mil
Прилегание к меди 1 oz с 30% заполнением	0.8 mil	0.9 mil
Прилегание к меди 1 oz с 70% заполнением	0.3 mil	0.4 mil
Прилегание к меди 2 oz с 30% заполнением	1.8 mil	1.9 mil
Прилегание к меди 2 oz с 70% заполнением	0.8 mil	0.8 mil
Расположен между двумя слоями препрега	9%	10%
Прилегание к внешнему слою	не изменяется	не изменяется

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

$$

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

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

Пример

Необходимо рассчитать финишную толщину стека, приведенного на рисунке. На всех слоях металлизации используется медь 1 oz. Исходная толщина препрега 2116 равна 5.1 mil.


Результирующий стек будет иметь вид:

Тип слоя	Начальная толщина	Изменение толщины	Финишная толщина
Внешний	1.35 mil	—	1.35 mil
Слой 2116	5.1 mil	—	5.1 mil
Слой 2116	5.1 mill	0.9 mil	4.2 mil
Внутренний сигнальный	1.35 mil	—	1.35 mil
Core	39 mil	—	39 mil
Внутренний Plane	1.35 mil	—	1.35 mil
Слой 2116	5.1 mil	0.4 mil	4.7 mil
Слой 2116	5.1 mil	—	5.1 mil
Внешний	1.35 mil	—	1.35 mil
		Итого:	63.5 mil ± 10%

Учет Etch Factor

Выражение для расчета Etch Factor для процесса электрического осаждения меди представлено на рисунке:

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

Тип слоя	Фабрика 1		Фабрика 2		Фабрика 3		Фабрика 4
	EF	W2-W1	EF	W2-W1	EF	W2-W1	EF	W2-W1
Внешний 0.5 oz	3.4 — 4	1 mil	3.4 — 4	1 mi	3.4 — 2	1.5 mil	2.6	—
Внешний 1 oz	—	—	—	—	1.66	2.4 mil	2.6	—
Внутренний 0.5 oz	1.75	0.8 mil	4.33	0.3 mil	1.73	1.75 mil	3	—
Внутренний 1 oz	2.4	1 mil	4.33	0.6 mil	2.6	1 mil	3	—
Внутренний 2 oz	—	1.5 — 2 mil	4.33	1.2 mil	2.6	2 mil	3	—
Внутренний 3 oz	—	—	—	—	2.6	3 mil	3	—
Внутренний 4 oz	—	—	—	—	2.3	4.5 mil	3	—

Для случаев, когда информация о значении EF от конкретного производства отсутствует – можно считать, что EF принимает следующие значения:

• внешние слои — 2.6
• внутренние слои — 3.7

Особенности расчета толщины металлизации

Металлизация внешних слоев

При расчете металлизации внешних слоев значение толщины меди весом 1 oz как правило принимается равным 1.37 mil. Рекомендуется отдельно задавать вес базовой меди и вес осаждаемой меди. Итоговое значение получается в результате суммирования этих двух параметров. Типовые значения приведены в таблице:

Base copper	Plating copper
	0.7oz	1oz	2oz
0.5oz	1.644 mil	2.055 mil	3.425 mil
1oz	2.329 mil	2.74 mil	4.11 mil
2oz	3.699 mil	4.11 mil	5.48 mil
3oz	5.069 mil	5.48 mil	6.85 mil

Металлизация внутренних слоев

Для внутренних слоев значение толщины меди весом 1 oz, как правило, принимается равным 1.3 mil.

Учет паяльной маски

При учёте паяльной маски опираемся на следующую схему:

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

• Dk — 3.7
• Df — 0.025
• Толщина — 0.8 mil

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

Некоторые фабрики считают значения C1 и C3 равными толщине металлизации (T1), а C2 – 0.8 mil. Правильность данного подхода приблизительно подтверждается реальными данными, полученными после производства PCB.

Один из наших PCB-партнеров считает толщину паяльной маски на сплошных участках меди 0.79 — 1.18 mil, на краях проводников 0.2 mil. Также данный производитель при расчете стека рекомендует не включать паяльную маску в расчет, так как при травлении внешних слоев происходит малейший перетрав (то есть увеличение значения импеданса), который маской компенсируется в номинал теоретического измерения импеданса внешних слоев без маски.
Это, кстати, хороший пример того, что при работе с данным производством — толщина трасс на вашей PCB будет меньше, чем заложено в рисунке печатной платы.

Итоги

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

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

Следуете ли вы БЭМу, и насколько он востребован вне Яндекса?

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

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

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

Идея была в том, чтобы ограничить возможности CSS для более предсказуемых результатов. Использовать минимум глобальных стилей и каждый отдельный элемент страницы делать блоком со своим уникальным классом и стилями, которые полностью его описывают. Селекторы по элементам и ID, хрупкие связки вложенности — всё это заменялось на простые селекторы по классам. Каждый класс в стилях — это блок. Благодаря этому блоки можно легко менять местами, вкладывать друг в друга и не бояться конфликтов или влияния.

#menu ul > li {
  color: old;
}
.menu-item {
  color: bem;
}

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

.block {}
.block_mod {}
.block__element {}
.block__element_mod {}

Эта многословность гарантирует уникальность элементов и модификаторов в рамках одного проекта. За уникальностью имён блоков вы следите сами, но это довольно просто, если каждый блок описан в отдельном файле. Глядя на такой класс в HTML или CSS, можно легко сказать, что это, и к чему оно относится.

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

Через пару лет в Яндексе окончательно сформулировали нотацию БЭМ. Любой интерфейс предлагалось разделять на блоки. Неотделимые части блоков — элементы. У тех и других есть модификаторы.

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

Для полной независимости блоков мало назвать классы правильно или изолировать стили, нужно собрать всё, что к нему относится. В проекте по БЭМу нет общего script.js или папки images со всеми картинками сайта. В одной папке с каждым блоком лежит всё, что нужно для его работы. Это позволяет удобно добавлять, удалять и переносить блоки между проектами. Потом, конечно, все ресурсы блоков при сборке объединяются в зависимости от задач проекта.

Когда БЭМ вышел за пределы Яндекса, сначала его воспринимали как магию и старались воспроизводить дословно, вплоть до префиксов b- у каждого блока. Такой смешной карго-культ.

.b-block {}
.b-block--mod {}
.b-block__element {}
.b-block__element--mod {}

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

.block {}
.block--mod {}
.block__element {}
.block__element--mod {}

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

Возьмём, к примеру, русский язык. Мы же пишем с прописной имена людей, названия и прочее такое? Пишем. Чтобы легко потом считывалось: это Надя или надежда на лучшее? Уж не говоря про знаки препинания и другие полезные договорённости. Вот буква «ё», например, смягчает… так, о чём мы? Да, БЭМ.

До БЭМа были проекты с портянками стилей, которые нельзя трогать. Они копились годами, слой за слоем, как обои в древней коммуналке. Их просто подключали первыми, а потом перезаписывали что мешало. Когда у вас есть div { font-size: 80% } — это даже уже не смешно.

/* Не смешно */

div {
  font-size: 80%;
}

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

Были и другие методологии: OOCSS Николь Салливан, SMACSS Джонатана Снука, вариации БЭМа и целые фреймворки. Даже у нас на продвинутом интенсиве можно было выбрать любую методологию для вёрстки учебного проекта.

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

Модульность и изоляцию стилей блока можно решить ещё лучше. Есть веб-компоненты, CSS-модули, куча решений CSS-в-JS и даже, прости господи, атомарный CSS. Но нет единого решения накопившихся проблем на следующие 10 лет, каким когда-то стал БЭМ. Что это будет? Посмотрим. Я ставлю на веб-компоненты.

А пока, если вы опишете интерфейс по БЭМу — код будет организован, предсказуем, расширяем и готов для повторного использования. Не только для вас, но и для других.

Видеоверсия

Вопросы можно задавать здесь.

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

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

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

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



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

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

Существует много нотаций описания диаграмм процессов, это IDEF0, BPMN, UML, EPC, CMMN и другие. Данная статья в равной степени относится к ним всем, в примерах использована нотация собственного приложения.

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

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

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

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

Шаг 1. Разместите свои цели как ресурсы в правом нижнем углу диаграммы.
Обычно процессы, которые имеет смысл описывать, имеют чётко выраженную конечную цель или группу целей. Такой целью может также служить состояние, после которого дальнейшее исполнение процесса не имеет смысла. Как правило, процессы создаются под конкретные цели, и зачастую очевидно, что написать в правом нижнем углу диаграммы. Однако иногда бывает дальновидным указать не только положительную цель, но перечислить состояния, в которых исполнение процесса прерывается, но исходная цель не достигнута или достигнута не полностью. Рекомендуется явно перечислять подобные негативные цели в случаях, если вероятность достижения основной цели ниже 60%.

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

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

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

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

Шаг 5. Проведите связи от имеющихся на диаграмме ресурсов к использующим их процессам; если необходимого для процесса ресурса нет на диаграмме, добавьте новую цель, вернувшись к Шагу 3 ^.
Очевидно, что если требуемого процессом ресурса нет, то это приводит к противоречию в исполнении задачи, так как соблюдены не все причины для желаемых следствий.  Следовательно, необходимо исполнить критерий полноты — всё необходимое для исполнения каждого процесса должно быть в наличии. Впрочем, не всегда оправдано явно указывать очевидные ресурсы, например, при обработке детали станком одним из очевидных ресурсов является электроэнергия, явное выделение этого ресурса, скорее всего, не сделает диаграмму понятнее, однако без значимых причин усложнит её. Помните о своей аудитории: часть диаграммы зритель всегда достраивает мысленно, это неизбежно. Старайтесь, чтобы мнимая часть диаграммы касалась очевидных всем моментов, более того, слишком явные вещи, выписанные на диаграмме, могут утомлять и даже раздражать.

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

Шаг 7. Убедитесь, что диаграмма легко читается и содержит не более 20 объектов; если это не так, сгруппируйте несколько контекстно связанных объектов в один объект подходящего типа с вложенной диаграммой, содержащей данную группу.
Практика показывает, что когда диаграмма содержит более 20 объектов (ресурсов или процессов), то схема перестаёт восприниматься цельно, а начинает выглядеть, как лабиринт, в котором зрителю нужно выискивать интересующие его пути. С другой стороны, редко какой проект или бизнес-процесс уложится в такое небольшое число объектов. К счастью, то, что не вместит одна диаграмма, поместится на нескольких, не стремитесь всё изложить сразу, помните: всегда можно сделать ещё одну диаграмму. 

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

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

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

Шаг 8. Убедитесь, что объекты имеют тип, соответствующий их сути, визуально разделите информационные и физические потоки. Если диаграмма содержит несколько контекстно связанных объектов, выделите их с помощью группы. В местах, требующих пояснений, разместите объекты типа комментарий.
В зависимости от выбранной нотации описания процессов нам будут доступны различные типы графических объектов, описывающих специфические аспекты задач, внимательно изучите перечень доступных объектов и используйте наиболее подходящее описание для каждой из задач. Иногда нотация позволяет отдельно выделить область на диаграмме, внутри которой можно расположить задачи, связанные каким-то общим признаком: исполнителем, местом исполнения и т. д.

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

Шаг 9. Для процессов, не являющихся элементарными операциями, постройте вложенную диаграмму, начиная с Шага 1.
На Шаге 7 мы синтетически создавали новую задачу из группы объектов и детализировали её вложенной диаграммой. На этом шаге делается то же самое, но аналитически: мы пытаемся сложный объект разложить на более простые процессы и отобразить их во вложенной диаграмме. В управлении проектами этот процесс называют структурной декомпозицией работ. Разбивая задачи на более мелкие или объединяя их в более крупные, следует следить, чтобы задачи одного уровня, отображаемые в одной диаграмме, были приблизительно равны по значимости и трудоёмкости.

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

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

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

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

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

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

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

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

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

Отдельное целостное преобразование данных в Talend называется задачей(job). Задача состоит из подзадач, которые, в свою очередь, состоят из компонент и связей. Компоненты непосредственно преобразуют данные либо занимаются вводом/выводом. Связи бывают нескольких типов. Основным средством обмена данными между компонентами являются связи типа “поток”(flow). Поток очень похож на таблицу в БД. У потока есть схема(названия, типы и атрибуты полей) и данные(значения полей). Как сами данные так и схема потока могут быть изменены в процессе обработки. Потоки в TOS не синхронизируются между собой. Они работают независимо друг от друга.

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

Предположим у есть нас CSV файл вида:

id,event_name,event_datetime,tag
1,"Hello, world!",2017-01-10T18:00:00Z,
2,"Event2",2017-01-10T19:00:00Z,tag1=q
3,Event3,2017-01-10T20:00:00Z,
4,"Hello, world!",2017-01-10T21:00:00Z,tag2=a
5,Event2,2017-01-10T22:00:00Z,
...

И мы хотим разделить данные по разным событиям(поле event).

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

Итак, первое что нам надо сделать это прочитать и распарсить CSV. Для начала создадим запись метаданных для нашего входного CSV файла — это упростит дальнейшую работу (Metadata -> File delimited). Создание File delimited происходит более или менее интуитивно, поэтому подробное описание спрятано под спойлером.

Единственное, что заслуживает упоминания, это расстановка кавычек, при подстановке значений в поля форм. Это относится не только к созданию File delimited но и к большинству других полей в формах. Дело в том, что большинство значений во всевозможных полях будут подставлены в Java код “как есть”, т.е. должны являться выражением Java определенного типа. Если мы задаем строковую константу ее придется написать в кавычках. Это дает нам дополнительную гибкость. Получается что везде, где требуется значение, можно подставить значение параметра или выражения.


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



Далее, настроим наш парсер. Для компонента tFileInputDelimited в настройках установим “Property type” в значение “Repository” и выберем ранее созданный шаблон.

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

Из этой ситуации есть два выхода. Первый — все время подменять файл из шаблона на нужный файл. Второй — развязать компонент парсера и шаблон. В этом случае настройки парсинга можно сохранить, но появляется возможность задать входной файл. Недостатки первого способа очевидны, к недостаткам второго относится отсутствие синхронизации между шаблоном и парсером. Если мы изменим шаблон то синхронизировать настройки парсера нужно будет вручную. Мы пойдем вторым путем и отвяжем парсер от шаблона. Для этого вернем значение “Build-In” в поле “Property type”. Настройки сохранились, но появилась возможность их менять.

Изменим имя входного файла на выражение context.INPUT_CSV. Обратите внимание, имя было в кавычках (строковая константа), а наше выражение без кавычек. Оно является параметром контекста. Также нужно создать этот параметр на вкладке контекста. Для отладки можно задать значение по умолчанию. Параметры контекста можно задавать как параметры командной строки (примерно так --context_param INPUT_CSV=path). Это относится к запуску собранного пакета Java.

Далее. Мы хотим разделить данные по именам событий.

Для этого потребуется компонент tMap и несколько tFilterRow. Давайте пока ограничимся двумя tFilterRow т.е. будем выделять только два разных события. Соединим их как показано на рисунке:



При соединении tMap и tFilterRow потребуется ввести имя для связи. Имя должно быть уникально. Далее нужно настроить компонент tMap. Для этого войдем в меню Map Editor либо дважды кликнув по иконке tMap, либо вызвав редактор из панели свойств компонента.

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



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

Настройка фильтров tFilterRow не представляет из себя ничего особенного.


Добавим после фильтров пару tLogRow, запустим и увидим что данные делятся. Единственно, лучше установить Mode для tLogRow в что-то отличное от “Основной”, иначе данные перемешаются.

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

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



Компонент Connection задает параметры доступа к базе и устанавливает соединение. Компонент Close отключается от базы. В среднем блоке, где на рисунке находится единственный компонент Commit, можно использовать базу данных не устанавливая новых соединений. Для этого в настройках компонентов нужно выбрать опцию “Использовать существующее соединение” и выбрать нужный компонент Connection.

Здесь также используется еще один механизм TOS — подзадачи (subjob). Путем создания подзадач можно добиться, чтобы некоторые части задачи завершались прежде, чем начнутся другие. В данной примере компонент Commit не начнет работу пока не установится соединение. Между подзадачами проводится связь OnSubjobOk (в контекстном меню компонента доступен пункт Trigger, внутри которого есть эта связь). Существуют и другие связи, например, ObSubjobError для обработки ошибок.

Вернемся к нашему примеру с CSV файлом.

Поле tag у нас не очень подходит для записи в базу данных — tag2=a. Наверняка мы захотим разделить пару ключ-значение по разным полям в базе. Это можно сделать разными способами, но мы сделаем это при помощи компонента tJavaFlex. tJavaFlex это компонент, поведение которого можно описать на языке Java. В его настройках присутствуют три секции — первая выполняется до начала обработки данных (инициализация), вторая занимается обработкой данных и третья выполняется после обработки всех данных. Также, как и у остальных компонент есть редактор схемы. Удалим из схемы данных на выходе поле tag и добавить пару новых — tag_name и tag_value (типа String).



Далее, в средней секции компонента напишем

row4.tag_name = "";
row4.tag_value = "";

if(row2.tag.contains("="))
{
String[] parts = row2.tag.split("=");
row4.tag_name = parts[0];
row4.tag_value = parts[1];
}

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



Таким образом, теги будут разделены на два поля. Однако нужно убедиться, что в настройках tJavaFlex стоит галочка “Авто-распространение данных”, иначе все остальные данные исчезнут. По сути мы просто дописали дополнительное преобразование. Прочие поля совпадают по названию и будут скопированы автоматически.

Далее я расскажу о двух чуть более сложных и конкретных вещах.

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

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

Для того чтобы добавить запись только в том случае если ее нет в Postgres можно использовать конструкцию вида
INSERT
WHERE NOT EXISTS
Сделать это можно при помощи компонента tPostgresqlRow. Это компонент позволяет выполнить произвольный SQL запрос. Но нам придется подставить в наш запрос реальные данные. Это можно сделать, например, так

String.format("
INSERT INTO tag(tag_name, tag_value)
	SELECT '%s', '%s'
	WHERE NOT EXISTS
	(SELECT * FROM tag
	WHERE tag_name = '%s'
	AND tag_value = '%s');",
input_row.tag_name, input_row.tag_value,
input_row.tag_name, input_row.tag_value)

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

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

String.format("
WITH T1 AS (
	SELECT * 
	FROM tag
	WHERE tag_name = '%s'
	AND tag_value = '%s'
), T2 AS (
	INSERT INTO tag(tag_name, tag_value)
	SELECT '%s', '%s'
	WHERE NOT EXISTS (SELECT * FROM T1)
	RETURNING tag_id
)
SELECT tag_id FROM T1
UNION ALL
SELECT tag_id FROM T2;",
input_row.tag_name, input_row.tag_value,
input_row.tag_name, input_row.tag_value)

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


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

Добавляем компонент tHashOutput и входящий поток, который хотим сохранить. Компоненту можно настроить на самостоятельную работу, либо на дописывание данных в другой tHashOutput компонент. В этом случае компонент будет работать подобно union из sql, т.е. данные будут записываться в один общий поток.Придется создать новую подзадачу, в которой будет осуществляться слияние. Не забудьте добавить связь OnSubjobOk.

Для каждого потока, работающего индивидуально, нужно создать компоненту tHashInput. У этой компоненты есть недостаток — даже после указания компоненты tHashOutput, из которой будут браться данные, схема не подгрузится автоматически. Далее все tHashInput нужно объединить при помощи tMap. Только один поток будет помечен как Main, по нему будут синхронизироваться остальные входящие потоки, а также исходящий, остальные входящие потоки будут Lookup. Кроме того нам надо задать связь между потоками, иначе мы получим Cross Join.



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

На этом все, спасибо всем кто дочитал до конца.

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

Некоторые люди здесь знают меня как основателя двух прибыльных SaaS проектов и автора популярных статей о них (статья про Postio, статья про Menumake). В этом тьюториале я расскажу о том как я, обыкновенный разработчик, в одиночку создавал свой первый глобальный проект и что из этого получилось (TL;DR: хеппи-энд и первые продажи). Ну и заодно пробежимся по всем проблемным вопросам, начиная о том как найти неконкурентную и гарантированно прибыльную идею (оставим создание следующего Гугла более амбициозным и умным людям), и заканчивая тем, как принимать платежи глобально, находясь при этом в России. Летс гоу.

Ищем идею

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


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



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

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

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



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



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

6688 заказов / 36 месяцев x $15 = $2786

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

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

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

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

Теперь за дело.

Создаем минимальный прототип

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

1. Сами тексты цитат
2. Изображения, незащищенные авторским правом
3. Красивые шрифты
4. Алгоритм, который смешает все это смузи вместе.

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

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

function autoWrap($text, $maxWidth, $maxHeight, $lineMargin, $fontName) {
  $image = new Imagick();
  $draw = new ImagickDraw();

  $startFontSize = round($this->height / 4);
  $fontSize = $startFontSize;

  $draw->setFont($fontName);

  $lineWidth = 10;
  $custom = false;
  
  $text = preg_replace('/\s+/', ' ', $text);
  
  while (true) {
    $draw->setFontSize($fontSize);

    $fit = false;

    while (true) {
      if ($custom == false) {
        $lines = explode("\n", wordwrap($text, $lineWidth, "\n", false));
      }

      $longestLine = 0;
      $longestLineIndex = 0;

      // Search for the longest line for the current font size
      foreach ($lines as $i => $line) {
        $fontMetrics = $image->QueryFontMetrics($draw, $line);

        if ($fontMetrics['textWidth'] > $longestLine) {
          $longestLine = $fontMetrics['textWidth'];
          $longestLineIndex = $i;

          /*
          if the longest line is longer than the width then get out
          of the outer loop without $fit = true
          */
          if ($longestLine > $maxWidth) {
            break 2;
          }
        }
      }

      $fit = true;
      $resultLines = $lines;
      $resultLineHeight = $fontMetrics['textHeight'];

      if (count($lines) == 1) {
        break;
      }

      $lineWidth++;
    }


    if ($fit) {
      $totalHeight = count($resultLines) * ($resultLineHeight + $lineMargin) - $lineMargin;

      if ($totalHeight <= $maxHeight) {
        break;
      }
    }
    $fontSize--;
  }

  return array($resultLines, $fontSize);
}

К концу второй недели разработки мой генератор мог создавать вот такие изображения:



Смотрится симпатично. Пока я игрался с генератором родилась идея делать анимированные гифки и видео с цитатами — достаточно просто генерировать последовательность кадров, а потом собирать ее в конечный файл. Для сборки в GIF использовался все тот же ImageMagick. Для создания MP4 я cначала создавал GIF, но потом перегонял его в видеофайл с помощью FFmpeg.

Все это дало возможность делать вот такой контент:







Почему бы не продавать его по удвоенной цене, увеличив таким образом средний чек?

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

Сайт

Для этого проекта я выбрал фреймворк Laravel и, несмотря на некоторые трудности…


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

Наверное, самая главная часть в сайте — это инструмент создания заказов. Он получился таким:

Прием платежей

Чтобы быть бизнесом, нам нужно как-то принимать платежи. Если бы мы продавали в России, я бы использовал решения типа Яндекс.Кассы или Робокассы. Если бы я был инкорпорирован в стране первого мира, я бы использовал Stripe или Braintree. Но в этот раз, я сорвал джекпот проблем из-за необходимости принимать платежи глобально (основные клиенты нашего с вами сервиса находятся в США), будучи инкорпорированным в России.

Единственной надежной системой, которую мне удалось найти, оказался Paypal. Они позволяют принимать платежи почти по всему миру, а потом выводить их на счет ООО или даже ИП, удерживая какие-то крохи комиссии. Все это, вместе с клевым российским налогом в 6%, удержало меня от желания инкорпорироваться в Делавере, Гонконге или Сингапуре в этот раз.

Процесс подключения к палке прост:

1. Создаете корпоративный аккаунт у них
2. Загружаете документы о своей компании
3. Ждете пару недель, отвечая на их письма с разными запросами
4. Интегрируетесь технически — это заняло у меня ровно один день.

Все, теперь вам могут платить со всего мира.

Массовая генерация изображений

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

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

База изображений и цитат

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

Лендинг

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


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

Статистика и логи

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

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



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


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

Сервер

Я ни разу не админ, поэтому, чтобы не париться с распараллеливанием генерации (ведь генерация изображений и тем более видео — затратный процесс), я решил просто арендовать мощный сервер у Hetzner и доверить деплой Laravel Forge. Оба продукта справились со своей задачей на пятерку.



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

Запуск

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



Сообщество PH отреагировало на проект очень положительно, и помимо классных отзывов и идей, принесло мне несколько продаж, две из США, одну из Великобритании:



Несмотря на то, что QuoteArtist (так я окрестил сервис) занял какое-то там 25-е место, он пробился на главную страницу платформы, что дало достаточно трафика:



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

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

Заключение

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

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

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

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

Зуд в голове

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

Наш ответ: может быть, и стоит! Прежде всего подумайте: у вас точно есть проект, который можно будет успешно и без проблем портировать на десктоп? Речь идет не только об интерфейсе и управлении, но и о модели продаж, ведь большинство игр в Steam платные, а ваши самые популярные проекты, вероятнее всего, free-to-play. Если в голову ничего подобного не приходит, то советуем серьезно задуматься, надо ли оно вам. Разработка с нуля — это большие траты и риски.

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

Все по-новому. Немного о Steam

Сразу заметим, что кроме Steam существует множество других систем дистрибуции, о которых рассказано вот в этом замечательном переводе от PatientZero. Если вы нацелены именно на эту платформу, то давайте будем честными, вы немного запоздали. По данным SteamSpy 38% всех игр Steam было выпущено в 2016 году. Это огромный рост количества продуктов. Сейчас Steam уже не так гостеприимен, как пять лет назад. Он куда менее активно привлекает аудиторию к вашей игре, и она может потеряться в потоке мусора, которого с каждым годом становится все больше и больше. Многие игроки рынка уходят на GOG и другие сервисы. Но, несмотря на это, Steam по-прежнему остается отличной площадкой с миллионной аудиторией, просто времена сейчас более сложные, чем, например, в 2010.



По данным SteamSpy.com, 38% всех игр было выпущено в 2016 году

Вот что мы имеем на данный момент (на 18 сентября, данные с SteamSpy):

• Всего в базе 17 000 игр (для сравнения: в Google Play или Apple AppStore их больше чем полтора миллиона)
• 47 миллионов активных пользователей за две недели

Общая прибыль игр в Steam в 2015-2017 году. 2/3 всего дохода приносят платные игры, но free-to-play набирает обороты. Скорее всего, половина красного графика — это игры от Valve.

Таким образом, нельзя сказать, что Steam – это уже уходящий поезд, но поторопиться не помешает.

Что нужно знать о Steam Direct?

Есть вы совсем не знакомы со Steam Direct и его историей, то советуем прочитать статью-перевод "Steam Greenlight и Steam Direct: что нужно знать инди-разработчикам". При переходе на Direct у вас отпадает необходимость особо возиться с аудиторией на стадии пререлиза. Это и хорошо, и плохо. Из хорошего: это обеспечит вам более простой выход на рынок, без помощи Greenlight. Из плохого: аудиторию нужно будет набирать с нуля, возможно, через соцсети, так как в момент выхода вашей игры в Steam внутри системы про неё никто не будет знать.

Все, что вам нужно для публикации — это $100, ряд документов и ваш проект.

Как начать свой путь?

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

Регистрация



В самом начале вам нужно создать собственный аккаунт в Steam, после чего перейти на страницу SteamWorks, где нужно будет заполнить информацию о вашей компании, ввести все необходимые сведения и оплатить Product Submission Fee в размере $100. Тут есть много нюансов (например, нужно правильно подать всю информацию, чтобы избежать двойного налогообложения), про которые мы, вероятно, напишем отдельную статью.

Публикация. Работа в Steamworks



Что такое Steamworks? SteamWorks — это интерфейс, который обеспечивает пользователям инструменты для разработки и публикации. Он предоставляет ряд возможностей, как например: интеграция с клиентом Steam, интеграция с комьюнити, добавление и редактирование достижений для игр и многое другое. Название Steamworks относится ко всей системе работы с проектом, включая панель управления и API Steam. О технических аспектах интеграции рекомендуем почитать в интересных статьях от товарища Dinisoid. В данном материале мы остановимся только на «админке».

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

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

Поддержка игры
Конечно, поддержка игры и работа с аудиторией — тема, достойная отдельной статьи. Главное, на что здесь хочется обратить внимание — не забывайте про сообщество! Steam – это отличный аккумулятор единомышленников, который формирует сильные социальные цепочки. Сервис сам выбирает, какие игры рекомендовать, в зависимости от того, насколько активно взаимодействует с ней сообщество. Поэтому применяйте все методы. Кроме стандартных страниц в соцсетях, обязательно используйте Центр сообщества, который по факту представляет собой Facebook для пользователей Steam. В Центре проходят все обсуждения, туда выкладывают скриншоты, туда пишут обзоры. Подробнее возможности этого инструмента мы рассмотрим чуть позже. Ну и конечно, не забывайте чаще обновлять игру. Даже мелкие фиксы напоминают игрокам, что вы про них не забыли и поддерживаете свой проект.

Что Steam делает для вас? Механизмы продвижения

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

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

Особенности стартовой страницы
Список «Популярное и рекомендуемое» из 12 игр, который состоит из рекомендаций для конкретного игрока.



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

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

Блок «Специальные предложения»



В этот блок помещают:

• Акции на выходных (распродажи, бесплатные выходные)
• Предложение дня
• Другие предложения с скидками

Блок персональных рекомендаций, у социально активной аудитории



Сюда входят:

• Рекомендации от друзей
• Ссылка на большой список рекомендаций, который строится на основе игрового опыта пользователя

Рекомендации кураторов



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

Блок «Недавние обновления»



Тут все просто и аналогично Apple AppStore и Google Play. Нужно чаще обновлять игру, чтобы она регулярно появлялась в списках актуальных.

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

Особенности работы и поддержки игры в Steam

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

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



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

Список рекомендаций всегда есть на главной странице, кроме того, во время распродаж Steam поощряет тех, кто просматривает эти списки до конца.



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



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

Рекомендации по оформлению аккаунта разработчика

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

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



Хороший пример подхода к порту мобильной игры

Еще пара моментов:

1. Если вы не крупный издатель, то желательно иметь не слишком много игр на аккаунте — 5-10 вполне достаточно. Большое количество продуктов при отсутствии громкого имени в Steam зародит в людях подозрение, что ваши тайтлы не отличаются высоким качеством.
2. У любой игры, даже небольшой, должен быть свой сайт проекта. Это может быть обычный лэндинг с ссылками, но он должен быть.

Рекомендации по оформлению страницы игры

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

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



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

Крайне агрессивная среда. Система рейтингов Steam

Отличие системы отзывов от Apple AppStore и Google Play
В мобильных сторах вы можете просто поставить 5 звездочек и уйти. В Steam действует более сложная система правил для желающих оставить отзыв, а вычисление общей оценки не сводится к расчету среднего арифметического.

Итак, правила:

• Отзыв обязательно должен содержать текст
• Нужно наиграть минимум 5 минут в игре, чтобы получить возможность написать обзор
• В системе не предусмотрено звезд и промежуточных оценок. Вы либо рекомендуете игру, либо нет
• Итоговая оценка определяется путем весьма специфических расчетов (см. таблицу)

Общая процентовка рейтинга игр в Steam (данные собственных подсчетов)

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

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

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

Ценообразование в Steam или не жадничайте ( но и не продешевите!)

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

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

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



Пример индексации цен. Обратите внимание на процент роста относительно российского рубля.

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



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



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

Уже было несколько случаев, когда игроки «роняли» оценку игры после внезапного повышения цен. Недавно таким образом пострадала компания Paradox Interactive, которая повысила расценки на 10-30%. Игроки очень возмутились подобными изменениями и изменили рейтинг игр в худшую сторону. Досталось даже новым и хорошим проектам, таким как Tyranny.



Последствия ценовых войн

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

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

Коротко о локализациях

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

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

Страшное грядет… распродажи

Достаточно известная картинка, которая показывает всю опасность распродаж

Итак, вы выложили игру, начали создавать сообщество и тут внезапно… распродажа! Все бегают, кричат, главная страница Steam кардинально меняется, и вы понимаете, что нужно что-то делать. Но что?

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

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

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

Заключение и ссылки на информацию

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

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

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

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

Steamworks – главная страница SteamWorks с помощью которой можно начать публиковать свою игру
Steamworks Doc — огромный портал с документацией по интеграции сервисов Steam в вашу игру
Steamworks Development — официальный канал на YouTube, в котором выложено множество видео-туториалов и примеров работы в SteamWorks
Steamworks.NET – фреймворк для интеграции Steamworks API в Unity
Steamworks Unreal – материал по интеграции Steamworks API в Unreal Engine 4



Спасибо за внимание! Продолжаем играть и разрабатывать игры!

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

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

Статьи серии:

• Как работает Android, часть 1
• Как работает Android, часть 2
• …

---

Говоря про Unix- и Linux-корни Android, нужно вспомнить и о других проектах операционных систем, влияние которых можно проследить в Android, хотя они и не являются его прямыми предками.

Я уже упомянул про BeOS, в наследство от которой Android достался Binder.

Plan 9 from Bell Labs

Plan 9 — потомок Unix, логическое продолжение, развитие его идей и доведение их до совершенства. Plan 9 был разработан в Bell Labs той же командой, которая создала Unix и C — над ним работали такие люди, как Ken Thompson, Rob Pike, Dennis Ritchie, Brian Kernighan, Tom Duff, Doug McIlroy, Bjarne Stroustrup, Bruce Ellis и другие.

В Plan 9 взаимодействие процессов между собой и с ядром системы реализовано не через многочисленные системные вызовы и механизмы IPC, а через виртуальные текстовые файлы и файловые системы (развитие принципа Unix «всё — это файл»). При этом каждая группа процессов «видит» файловую систему по-своему (пространства имён, namespaces), что позволяет запускать разные части системы в разном окружении.

Например, чтобы получить позицию курсора мыши, приложения читают текстовый файл /dev/mouse. Оконная система rio предоставляет каждому приложению свою версию этого файла, в которой видны только события, относящиеся к окну этого приложения, и используются локальные по отношению к окну координаты. Сама rio читает события «настоящей» мыши через такой же файл /dev/mouse — в том виде, в котором его видит она. Если она запущена напрямую, этот файл предоставляется ядром и действительно описывает движения настоящей мыши, но она может быть совершенно прозрачно запущена в качестве приложения под другой копией rio, без какой-то специальной поддержки с её стороны.

Plan 9 полностью поддерживает доступ к удалённым файловым системам (используется собственный протокол 9P, кроме того, поддерживаются FTP и SFTP), что позволяет программам совершенно прозрачно получать доступ к удалённым файлам, интерфейсам и ресурсам. Такая «родная» сетевая прозрачность превращает Plan 9 в распределённую операционную систему — пользователь может физически находиться за одним компьютером, на котором запущена rio, запускать приложения на нескольких других, использовать в них файлы, хранящиеся на файловом сервере и выполнять вычисления на CPU-сервере — всё это полностью прозрачно и без специальной поддержки со стороны каждой из частей системы.

За счёт красиво спроектированной архитектуры Plan 9 значительно проще и меньше, чем Unix — на самом деле ядро Plan 9 даже в несколько раз меньше известного микроядра Mach.

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.

Несмотря на техническое превосходство и наличие слоя совместимости с Unix, Plan 9 не получил широкого распространения. Тем не менее, многие идеи и технологии из Plan 9 получили распространение и были реализованы в других системах. Самая известная из них — кодировка UTF-8, которая была разработана в Plan 9 для обеспечения полной поддержки Unicode при сохранении обратной совместимости с ASCII — стала общепринятым стандартом.

Больше всего идей и технологий из Plan 9 реализовано в Linux:

• файловая система /proc (procfs)
• системный вызов clone (аналог rfork из Plan 9)
• поддержка пространств имён монтирования (mount namespaces)
• поддержка файловых систем, реализованных в пользовательском пространстве (filesystem in userspace, FUSE)
• поддержка протокола 9P

Многое из этого используется, в том числе, и в Android. Кроме того, в Android реализован механизм intent’ов, похожий на plumber из Plan 9; о нём я расскажу в следующей статье.

Про Plan 9 можно узнать подробнее на сайте plan9.bell-labs.com (сохранённая копия в Wayback Machine), или его зеркале 9p.io

Inferno

Plan 9 получил продолжение в виде проекта Inferno, тоже разработанного в Bell Labs. К таким свойствам Plan 9, как простота и распределённость, Inferno добавляет переносимость. Программы для Inferno пишутся на высокоуровневом языке Limbo и выполняются — с использованием just-in-time компиляции — встроенной в ядро Inferno виртуальной машиной.

Inferno настолько переносим, что может запускаться

• на процессорах разных архитектур: ARM, x86, IBM PowerPC, Sun SPARC, 6SGI MIPS и HP PA-RISC,
• как самостоятельная операционная система или как программа под Plan 9, Unix, Windows 95 и Windows NT.

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

Inferno получил ещё меньше распространения и известности, чем Plan 9. С другой стороны, Inferno во многом предвосхитил Android, самую популярную операционную систему на свете.

Danger

Компания Danger Research Inc. была сооснована Энди Рубином (Andy Rubin) в 1999 году, за 4 года до сооснования им же Android Inc. в 2004 году.

В 2002 году Danger выпустили свой смартфон Danger Hiptop. Многие из разработчиков Danger впоследствии работали над Android, поэтому неудивительно, что его операционная система была во многом похожа на Android. Например, в ней были реализованы:

• «всегда запущенные» приложения, написанные на Java,
• полноценный веб-браузер,
• веб-приложения,
• мессенджер,
• email client,
• облачная синхронизация,
• магазин сторонних приложений.

Подробнее о Danger можно прочитать в статье Chris DeSalvo, одного из разработчиков, под названием The future that everyone forgot.

Java

Хотя использование высокоуровневых языков для серьёзной разработки сейчас уже никого не удивляет, из популярных операционных систем только у Android «родной» язык — высокоуровневая Java (с другой стороны, здесь можно вспомнить веб с его JavaScript, .NET для Windows и относительно высокоуровневый — но полностью компилируемый в нативный код и не использующий сборку мусора — Swift).

Несмотря на кажущиеся недостатки («Java сочетает в себе красоту синтаксиса C++ со скоростью выполнения питона»), Java обладает множеством преимуществ.

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

Программы на Java, как и на многих других высокоуровневых языках, переносимы между операционными системами и архитектурами процессора («Write once, run anywhere»). Практически это проявляется, например, в том, что приложения для Android работают без перекомпиляции на устройствах любой архитектуры (Android поддерживает ARM, ARM64, x86, x86–64 и MIPS).

В отличие от низкоуровневых языков вроде C и C++, использующих ручное управление памятью, в Java память автоматически управляется средой времени выполнения (runtime environment). Программа на Java даже не имеет прямого доступа к памяти, что автоматически предотвращает несколько классов ошибок, часто приводящих к падениям и уязвимостям в программах, написанных на низкоуровневых языках — невозможны «висячие ссылки» (из-за которых происходит use-after-free), разыменование нулевого указателя (при попытке это сделать выбрасывается NullPointerException), чтение неинициализированной памяти и выход за границы массива.

Использование полноценной сборки мусора (по сравнению с automatic reference counting) избавляет программиста от всех проблем и сложностей с циклическими ссылками и позволяет реализовывать ещё более продвинутые (advanced) зависимости между объектами.

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

Running Java is ART

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

Хотя делаются попытки создать физический процессор, который исполнял бы Java-байткод напрямую, в подавляющем большинстве случаев в качестве такого процессора используется эмулятор — Java virtual machine (JVM). Обычно используется реализация от Oracle/OpenJDK под названием HotSpot.

В Android используется собственная реализация под названием Android Runtime (ART), специально оптимизированная для работы на мобильных устройствах. В старых версиях Android (до 5.0 Lollipop) вместо ART использовалась другая реализация под названием Dalvik.

И в Dalvik, и в ART используется собственный формат байткода и собственный формат файлов, в которых хранится байткод — DEX (Dalvik executable). В отличие от class-файлов в «обычной джаве», весь Java-код приложения обычно компилируется в один DEX-файл classes.dex. При сборке Android-приложения Java-код сначала компилируется обычным компилятором Java в class-файлы, а потом конвертируется в DEX-файл специальной утилитой (возможно и обратное преобразование).

И HotSpot, и Dalvik, и ART дополнительно оптимизируют выполняемый код. Все три используют just-in-time compilation (JIT), то есть во время выполнения компилируют байткод в куски полностью нативного кода, который выполняется напрямую. Кроме очевидного выигрыша в скорости, это позволяет оптимизировать код для выполнения на конкретном процессоре, не отказываясь от полной переносимости байткода.

Кроме того, ART может компилировать байткод в нативный код заранее, а не во время выполнения (ahead-of-time compilation) — причём система автоматически планирует эту компиляцию на то время, когда устройство не используется и подключено к зарядке (например, ночью). При этом ART учитывает данные, собранные профилировщиком во время предыдущих запусков этого кода (profile-guided optimization). Такой подход позволяет дополнительно оптимизировать код под специфику работы конкретного приложения и даже под особенности использования этого приложения именно этим пользователем.

В результате всех этих оптимизаций производительность Java-кода на Android не сильно уступает производительности низкоуровневого кода (на C/C++), а в некоторых случаях и превосходит её.

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

Существуют как JVM-реализации независимых языков — например, Jython для Python, JRuby для Ruby, Rhino для JavaScript и диалект Lisp Clojure — так и языки, исходно разработанные для компиляции в Java-байткод и выполнения на JVM, самые известные из которых — Groovy, Scala и Kotlin.

Самый новый из них, Kotlin, специально разработанный для идеальной совместимости с Java и обладающий гораздо более приятным синтаксисом (похожим на Swift), поддерживается Google как официальный язык разработки под Android наравне с Java.

Несмотря на все преимущества Java, в некоторых случаях всё-таки желательно использовать низкоуровневый язык — например, для реализации критичного по производительности компонента, такого как браузерный движок, или чтобы использовать существующую нативную библиотеку. Java позволяет вызывать нативный код через Java Native Interface (JNI), и Android предоставляет специальные средства для нативной разработки — Native Development Kit (NDK), в который входят в том числе заголовочные файлы, компилятор (Clang), отладчик (LLDB) и система сборки.

Хотя NDK в основном ориентирован на использование C/C++, с его помощью можно писать под Android и на других языках — в том числе Rust, Swift, Python, JavaScript и даже Haskell. Больше того, есть даже возможность портировать iOS-приложения (написанные на Objective-C или Swift) на Android практически без изменений.

О безопасности

Классический Unix

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

По смыслу каждый UID (user ID) соответствует своему пользователю — во времена создания Unix была нормальной ситуация, когда один компьютер одновременно использовался множеством людей. Таким образом, в Unix процессы и файлы разных людей были защищены друг от друга. Чтобы разрешить общий доступ к некоторым файлам, пользователи объединялись в группы, которым и соответствовал GID (group ID).

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

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

В Unix есть и исключение из ограничений доступа — UID 0, который принято называть root. У него есть доступ ко всему в системе, и никакие ограничения на него не распространяются. Этот аккаунт использовался системным администратором; кроме того, под UID 0 запускаются многие системные сервисы.

В современном Linux эта модель была значительно расширена и обобщена, в том числе появились capabilities, позволяющие «получить часть root-прав», и реализующая мандатное управление доступом (mandatory access control, MAC) подсистема SELinux, которая позволяет дополнительно ограничить права (в том числе права root-процессов).

Всё изменилось

За несколько десятков лет, прошедших с создания Unix до создания Android, практика использования компьютеров («вычислителей») значительно изменилась.

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

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

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

Android

Хотя часть Android-приложений поставляется с системой — например, такие стандартные приложения, как Калькулятор, Часы и Камера — большинство приложений пользователи устанавливают из сторонних источников. Самый известный из них — Google Play Store, но есть и другие, например, F-Droid, Amazon Appstore, Яндекс.Store, китайские Baidu App Store, Xiaomi App Store, Huawei App Store и т.д. Кроме того, Android позволяет вручную устанавливать произвольные приложения из APK-файлов (это называют sideloading).

Как и другие Unix-подобные системы, Android использует для ограничения доступа существующий механизм UID/GID. При этом — в отличие от традиционного использования, когда UID соответствуют пользователям — в Android разные UID соответствуют разным приложениям. Поскольку процессы разных приложений запускаются с разными UID, уже на уровне ядра приложения защищены и изолированы друг от друга и не имеют доступа к системе и данным пользователя. Это образует песочницу (Application Sandbox) и позволяет пользователю устанавливать любые приложения без необходимости доверять им.

Чтобы всё-таки получить доступ к пользовательским данным, камере, совершению звонков и т.п., приложение должно получить от пользователя разрешение (permission). Некоторые из разрешений существуют в виде GID, в которые приложение добавляется, когда получает это разрешение — например, получение разрешения ACCESS_FM_RADIO помещает приложение в группу media, что позволяет ему получить доступ к файлу /dev/fm. Остальные существуют только на более высоком уровне (в виде записей в файле packages.xml) и проверяются другими компонентами системы при обращении к высокоуровневому API через Binder.

Небольшая часть системных сервисов в Android запускается под UID 0, то есть root, но большинство используют специально выделенные номера UID, повышая при необходимости свои права с помощью Linux capabilities. Кроме того, Android использует SELinux — использование SELinux в Android называют SEAndroid — для ещё большего ограничения того, какие действия разрешено выполнять приложениям и системным сервисам.

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

---

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

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

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

Статьи серии:

• Как работает Android, часть 1
• Как работает Android, часть 2
• …

---

Говоря про Unix- и Linux-корни Android, нужно вспомнить и о других проектах операционных систем, влияние которых можно проследить в Android, хотя они и не являются его прямыми предками.

Я уже упомянул про BeOS, в наследство от которой Android достался Binder.

Plan 9 from Bell Labs

Plan 9 — потомок Unix, логическое продолжение, развитие его идей и доведение их до совершенства. Plan 9 был разработан в Bell Labs той же командой, которая создала Unix и C — над ним работали такие люди, как Ken Thompson, Rob Pike, Dennis Ritchie, Brian Kernighan, Tom Duff, Doug McIlroy, Bjarne Stroustrup, Bruce Ellis и другие.

В Plan 9 взаимодействие процессов между собой и с ядром системы реализовано не через многочисленные системные вызовы и механизмы IPC, а через виртуальные текстовые файлы и файловые системы (развитие принципа Unix «всё — это файл»). При этом каждая группа процессов «видит» файловую систему по-своему (пространства имён, namespaces), что позволяет запускать разные части системы в разном окружении.

Например, чтобы получить позицию курсора мыши, приложения читают текстовый файл /dev/mouse. Оконная система rio предоставляет каждому приложению свою версию этого файла, в которой видны только события, относящиеся к окну этого приложения, и используются локальные по отношению к окну координаты. Сама rio читает события «настоящей» мыши через такой же файл /dev/mouse — в том виде, в котором его видит она. Если она запущена напрямую, этот файл предоставляется ядром и действительно описывает движения настоящей мыши, но она может быть совершенно прозрачно запущена в качестве приложения под другой копией rio, без какой-то специальной поддержки с её стороны.

Plan 9 полностью поддерживает доступ к удалённым файловым системам (используется собственный протокол 9P, кроме того, поддерживаются FTP и SFTP), что позволяет программам совершенно прозрачно получать доступ к удалённым файлам, интерфейсам и ресурсам. Такая «родная» сетевая прозрачность превращает Plan 9 в распределённую операционную систему — пользователь может физически находиться за одним компьютером, на котором запущена rio, запускать приложения на нескольких других, использовать в них файлы, хранящиеся на файловом сервере и выполнять вычисления на CPU-сервере — всё это полностью прозрачно и без специальной поддержки со стороны каждой из частей системы.

За счёт красиво спроектированной архитектуры Plan 9 значительно проще и меньше, чем Unix — на самом деле ядро Plan 9 даже в несколько раз меньше известного микроядра Mach.

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.

Несмотря на техническое превосходство и наличие слоя совместимости с Unix, Plan 9 не получил широкого распространения. Тем не менее, многие идеи и технологии из Plan 9 получили распространение и были реализованы в других системах. Самая известная из них — кодировка UTF-8, которая была разработана в Plan 9 для обеспечения полной поддержки Unicode при сохранении обратной совместимости с ASCII — стала общепринятым стандартом.

Больше всего идей и технологий из Plan 9 реализовано в Linux:

• файловая система /proc (procfs)
• системный вызов clone (аналог rfork из Plan 9)
• поддержка пространств имён монтирования (mount namespaces)
• поддержка файловых систем, реализованных в пользовательском пространстве (filesystem in userspace, FUSE)
• поддержка протокола 9P

Многое из этого используется, в том числе, и в Android. Кроме того, в Android реализован механизм intent’ов, похожий на plumber из Plan 9; о нём я расскажу в следующей статье.

Про Plan 9 можно узнать подробнее на сайте plan9.bell-labs.com (сохранённая копия в Wayback Machine), или его зеркале 9p.io

Inferno

Plan 9 получил продолжение в виде проекта Inferno, тоже разработанного в Bell Labs. К таким свойствам Plan 9, как простота и распределённость, Inferno добавляет переносимость. Программы для Inferno пишутся на высокоуровневом языке Limbo и выполняются — с использованием just-in-time компиляции — встроенной в ядро Inferno виртуальной машиной.

Inferno настолько переносим, что может запускаться

• на процессорах разных архитектур: ARM, x86, IBM PowerPC, Sun SPARC, 6SGI MIPS и HP PA-RISC,
• как самостоятельная операционная система или как программа под Plan 9, Unix, Windows 95 и Windows NT.

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

Inferno получил ещё меньше распространения и известности, чем Plan 9. С другой стороны, Inferno во многом предвосхитил Android, самую популярную операционную систему на свете.

Danger

Компания Danger Research Inc. была сооснована Энди Рубином (Andy Rubin) в 1999 году, за 4 года до сооснования им же Android Inc. в 2004 году.

В 2002 году Danger выпустили свой смартфон Danger Hiptop. Многие из разработчиков Danger впоследствии работали над Android, поэтому неудивительно, что его операционная система была во многом похожа на Android. Например, в ней были реализованы:

• «всегда запущенные» приложения, написанные на Java,
• полноценный веб-браузер,
• веб-приложения,
• мессенджер,
• email client,
• облачная синхронизация,
• магазин сторонних приложений.

Подробнее о Danger можно прочитать в статье Chris DeSalvo, одного из разработчиков, под названием The future that everyone forgot.

Java

Хотя использование высокоуровневых языков для серьёзной разработки сейчас уже никого не удивляет, из популярных операционных систем только у Android «родной» язык — высокоуровневая Java (с другой стороны, здесь можно вспомнить веб с его JavaScript, .NET для Windows и относительно высокоуровневый — но полностью компилируемый в нативный код и не использующий сборку мусора — Swift).

Несмотря на кажущиеся недостатки («Java сочетает в себе красоту синтаксиса C++ со скоростью выполнения питона»), Java обладает множеством преимуществ.

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

Программы на Java, как и на многих других высокоуровневых языках, переносимы между операционными системами и архитектурами процессора («Write once, run anywhere»). Практически это проявляется, например, в том, что приложения для Android работают без перекомпиляции на устройствах любой архитектуры (Android поддерживает ARM, ARM64, x86, x86–64 и MIPS).

В отличие от низкоуровневых языков вроде C и C++, использующих ручное управление памятью, в Java память автоматически управляется средой времени выполнения (runtime environment). Программа на Java даже не имеет прямого доступа к памяти, что автоматически предотвращает несколько классов ошибок, часто приводящих к падениям и уязвимостям в программах, написанных на низкоуровневых языках — невозможны «висячие ссылки» (из-за которых происходит use-after-free), разыменование нулевого указателя (при попытке это сделать выбрасывается NullPointerException), чтение неинициализированной памяти и выход за границы массива.

Использование полноценной сборки мусора (по сравнению с automatic reference counting) избавляет программиста от всех проблем и сложностей с циклическими ссылками и позволяет реализовывать ещё более продвинутые (advanced) зависимости между объектами.

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

Running Java is ART

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

Хотя делаются попытки создать физический процессор, который исполнял бы Java-байткод напрямую, в подавляющем большинстве случаев в качестве такого процессора используется эмулятор — Java virtual machine (JVM). Обычно используется реализация от Oracle/OpenJDK под названием HotSpot.

В Android используется собственная реализация под названием Android Runtime (ART), специально оптимизированная для работы на мобильных устройствах. В старых версиях Android (до 5.0 Lollipop) вместо ART использовалась другая реализация под названием Dalvik.

И в Dalvik, и в ART используется собственный формат байткода и собственный формат файлов, в которых хранится байткод — DEX (Dalvik executable). В отличие от class-файлов в «обычной джаве», весь Java-код приложения обычно компилируется в один DEX-файл classes.dex. При сборке Android-приложения Java-код сначала компилируется обычным компилятором Java в class-файлы, а потом конвертируется в DEX-файл специальной утилитой (возможно и обратное преобразование).

И HotSpot, и Dalvik, и ART дополнительно оптимизируют выполняемый код. Все три используют just-in-time compilation (JIT), то есть во время выполнения компилируют байткод в куски полностью нативного кода, который выполняется напрямую. Кроме очевидного выигрыша в скорости, это позволяет оптимизировать код для выполнения на конкретном процессоре, не отказываясь от полной переносимости байткода.

Кроме того, ART может компилировать байткод в нативный код заранее, а не во время выполнения (ahead-of-time compilation) — причём система автоматически планирует эту компиляцию на то время, когда устройство не используется и подключено к зарядке (например, ночью). При этом ART учитывает данные, собранные профилировщиком во время предыдущих запусков этого кода (profile-guided optimization). Такой подход позволяет дополнительно оптимизировать код под специфику работы конкретного приложения и даже под особенности использования этого приложения именно этим пользователем.

В результате всех этих оптимизаций производительность Java-кода на Android не сильно уступает производительности низкоуровневого кода (на C/C++), а в некоторых случаях и превосходит её.

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

Существуют как JVM-реализации независимых языков — например, Jython для Python, JRuby для Ruby, Rhino для JavaScript и диалект Lisp Clojure — так и языки, исходно разработанные для компиляции в Java-байткод и выполнения на JVM, самые известные из которых — Groovy, Scala и Kotlin.

Самый новый из них, Kotlin, специально разработанный для идеальной совместимости с Java и обладающий гораздо более приятным синтаксисом (похожим на Swift), поддерживается Google как официальный язык разработки под Android наравне с Java.

Несмотря на все преимущества Java, в некоторых случаях всё-таки желательно использовать низкоуровневый язык — например, для реализации критичного по производительности компонента, такого как браузерный движок, или чтобы использовать существующую нативную библиотеку. Java позволяет вызывать нативный код через Java Native Interface (JNI), и Android предоставляет специальные средства для нативной разработки — Native Development Kit (NDK), в который входят в том числе заголовочные файлы, компилятор (Clang), отладчик (LLDB) и система сборки.

Хотя NDK в основном ориентирован на использование C/C++, с его помощью можно писать под Android и на других языках — в том числе Rust, Swift, Python, JavaScript и даже Haskell. Больше того, есть даже возможность портировать iOS-приложения (написанные на Objective-C или Swift) на Android практически без изменений.

О безопасности

Классический Unix

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

По смыслу каждый UID (user ID) соответствует своему пользователю — во времена создания Unix была нормальной ситуация, когда один компьютер одновременно использовался множеством людей. Таким образом, в Unix процессы и файлы разных людей были защищены друг от друга. Чтобы разрешить общий доступ к некоторым файлам, пользователи объединялись в группы, которым и соответствовал GID (group ID).

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

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

В Unix есть и исключение из ограничений доступа — UID 0, который принято называть root. У него есть доступ ко всему в системе, и никакие ограничения на него не распространяются. Этот аккаунт использовался системным администратором; кроме того, под UID 0 запускаются многие системные сервисы.

В современном Linux эта модель была значительно расширена и обобщена, в том числе появились capabilities, позволяющие «получить часть root-прав», и реализующая мандатное управление доступом (mandatory access control, MAC) подсистема SELinux, которая позволяет дополнительно ограничить права (в том числе права root-процессов).

Всё изменилось

За несколько десятков лет, прошедших с создания Unix до создания Android, практика использования компьютеров («вычислителей») значительно изменилась.

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

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

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

Android

Хотя часть Android-приложений поставляется с системой — например, такие стандартные приложения, как Калькулятор, Часы и Камера — большинство приложений пользователи устанавливают из сторонних источников. Самый известный из них — Google Play Store, но есть и другие, например, F-Droid, Amazon Appstore, Яндекс.Store, китайские Baidu App Store, Xiaomi App Store, Huawei App Store и т.д. Кроме того, Android позволяет вручную устанавливать произвольные приложения из APK-файлов (это называют sideloading).

Как и другие Unix-подобные системы, Android использует для ограничения доступа существующий механизм UID/GID. При этом — в отличие от традиционного использования, когда UID соответствуют пользователям — в Android разные UID соответствуют разным приложениям. Поскольку процессы разных приложений запускаются с разными UID, уже на уровне ядра приложения защищены и изолированы друг от друга и не имеют доступа к системе и данным пользователя. Это образует песочницу (Application Sandbox) и позволяет пользователю устанавливать любые приложения без необходимости доверять им.

Чтобы всё-таки получить доступ к пользовательским данным, камере, совершению звонков и т.п., приложение должно получить от пользователя разрешение (permission). Некоторые из разрешений существуют в виде GID, в которые приложение добавляется, когда получает это разрешение — например, получение разрешения ACCESS_FM_RADIO помещает приложение в группу media, что позволяет ему получить доступ к файлу /dev/fm. Остальные существуют только на более высоком уровне (в виде записей в файле packages.xml) и проверяются другими компонентами системы при обращении к высокоуровневому API через Binder.

Небольшая часть системных сервисов в Android запускается под UID 0, то есть root, но большинство используют специально выделенные номера UID, повышая при необходимости свои права с помощью Linux capabilities. Кроме того, Android использует SELinux — использование SELinux в Android называют SEAndroid — для ещё большего ограничения того, какие действия разрешено выполнять приложениям и системным сервисам.

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

---

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

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

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

Откуда у беды ноги растут?

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

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

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

• CRM-система не нравится техническому отделу, сисадмину либо просто имеет технические проблемы — например, медленно загружается и обрабатывает данные, подвешивает машину (десктоп) или крашит браузер (web). Увы, такое встречается — не каждая компания решается проводить постоянный рефакторинг кода для оптимизации своего ПО. Мы в RegionSoft очень заморочены скоростью — от релиза к релизу мы оптимизируем код, заботимся о размере программы, скорости отклика и обработки данных. К сожалению, не все на рынке так делают — грустно, но некоторые системы запускаются дольше, чем остывает/пьётся утренний кофе.
  
• Сами сотрудники блокируют использование CRM-системы — потихоньку ей не пользуются, рассчитывая, что «само рассосётся» и все забудут, что в неё нужно что-то вносить. Периодически после очередного разноса данные тщательно заносятся, а потом снова тишина. Причины две. Первая — страх контроля над действиями сотрудников. Вторая, более глубокая, страх нового — ничем не отличающийся от неприязни к новому смартфону или непривычного управления новым автомобилем.
  

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

На самом деле, для очень большей части компаний сектора СМБ CRM-система — это не очень сложно и даже не очень дорого. Фактически это инструмент, такой же как ПК, IP-телефония, офисный пакет. Представьте себе, в 2001 году агентство Forrester оценивало среднюю стоимость внедрения CRM в $40-60 тыс., а срок внедрения — в 24 месяца. Срок 90 дней назывался как сенсационное исключение, граничащее с пустыми обещаниями вендора. Сейчас эти параметры касаются крупных сложных внедрений, даже скорее интеграционных проектов с доработкой и т.д. А небольшому бизнесу, купившему CRM-систему, нужно предпринять лишь несколько базовых шагов, чтобы начать эффективно работать и наращивать мощность и продуктивность своей CRM-системы. Поговорим о них.

Чек-лист успешного старта CRM-системы

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

Учиться, учиться, ещё раз учиться

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

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

Рассказывает наш сотрудник: «Когда я пришёл работать в крупного интегратора решений VoIP, думал, что будет некомфортно — рабочее место должны были оборудовать в течение трёх дней. Мне не хотелось сидеть и видеть, как куча народу работает, а я разглядываю цветы на подоконнике или тыкаю в телефон. Однако я был избавлен от этого — мне сразу дали распечатки базовой информации о продукте, а потом подцепили планшет к внутренней сети и открыли крутой портал с информацией по всем вопросам — его создали сами сотрудники. Я потом тоже вписал туда не одну статью. Кстати, это была CRM, а не Jira. В ней же велись продажи, маркетинг и управление персоналом».  

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

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

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

Практика — first

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

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

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

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

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

Оперативная работа в CRM — привычка свыше нам дана

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

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

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

Да я жить без CRM не могу

Помните вот эту байку с Баша?



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

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

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

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

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

Ошибки, мешающие восприятию CRM-системы

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

1. Купили CRM по принципу «чем дороже, тем лучше». Как правило, в очень дорогих системах много лишних для СМБ функций, дорогое обучение, дорогая поддержка, сложная настройка. Дело не в цене, дело в том, насколько система отвечает потребностям вашего бизнеса.
   
2. Повелись на внедрение CRM за один день или две недели. Мы реально знаем вендоров, которые обещают любое внедрение за пару недель. Настройтесь на то, что это маркетинговая фишка — если вы морально приготовитесь к месяцу, а внедрение займёт три, вам покажется, что силы уже исчерпаны и пользование CRM-кой начнётся с недовольства.
   
3. Воспринимаете CRM как статичное хранилище данных и просто забиваете туда клиентов. Это неправильно — мы все уже давно ушли от контакт-менеджеров и предлагаем решения, которые делают работу быстрой и простой. Раз вы за это заплатили, зачем ходить пешком не стоит игнорировать такие возможности.
   
4. Вы избегаете CRM — вам кажется, что дела и так идут хорошо. Поверьте нашему опыту — это до первого увольнения ключевого сотрудника и до первого увода клиенсткой базы.
   

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


Собственно, вот вам и пример как раз шаблонного мышления менеджера

Мне ничего не помогло, CRM всё равно простаивает

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

CRM-систем сейчас много: новых и развитых, облачных, web, десктопных, дорогих и доступных, мощных и урезанных. В 1989 году в зарубежной прессе было всего одно упоминание CRM, сегодня это сотни тысяч запросов по всем миру. Жить без CRM-системы в 2017 году — откровенно, не самая лучшая идея, поскольку автоматизация давно стала конкурентным преимуществом. Стоит начать процесс внедрения, и вскоре вы поймёте, как менять процессы бизнеса, оптимизировать их, чтобы зарабатывать больше и работать продуктивнее. Дело-то за малым — начать.

P.S.: у нас идёт акция «Осеннее ускорение», так что если кому-то нужна скидка 15% на разный бизнес-софт (а мы делаем не только CRM-системы), то рады вам помочь, рассказать, провести бесплатную онлайн-презентацию — вы можете всё посмотреть и расспросить, не вставая с любимого кресла. Отвечаем даже на неудобные вопросы (по делу, конечно).

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

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

Откуда у беды ноги растут?

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

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

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

• CRM-система не нравится техническому отделу, сисадмину либо просто имеет технические проблемы — например, медленно загружается и обрабатывает данные, подвешивает машину (десктоп) или крашит браузер (web). Увы, такое встречается — не каждая компания решается проводить постоянный рефакторинг кода для оптимизации своего ПО. Мы в RegionSoft очень заморочены скоростью — от релиза к релизу мы оптимизируем код, заботимся о размере программы, скорости отклика и обработки данных. К сожалению, не все на рынке так делают — грустно, но некоторые системы запускаются дольше, чем остывает/пьётся утренний кофе.
  
• Сами сотрудники блокируют использование CRM-системы — потихоньку ей не пользуются, рассчитывая, что «само рассосётся» и все забудут, что в неё нужно что-то вносить. Периодически после очередного разноса данные тщательно заносятся, а потом снова тишина. Причины две. Первая — страх контроля над действиями сотрудников. Вторая, более глубокая, страх нового — ничем не отличающийся от неприязни к новому смартфону или непривычного управления новым автомобилем.
  

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

На самом деле, для очень большей части компаний сектора СМБ CRM-система — это не очень сложно и даже не очень дорого. Фактически это инструмент, такой же как ПК, IP-телефония, офисный пакет. Представьте себе, в 2001 году агентство Forrester оценивало среднюю стоимость внедрения CRM в $40-60 тыс., а срок внедрения — в 24 месяца. Срок 90 дней назывался как сенсационное исключение, граничащее с пустыми обещаниями вендора. Сейчас эти параметры касаются крупных сложных внедрений, даже скорее интеграционных проектов с доработкой и т.д. А небольшому бизнесу, купившему CRM-систему, нужно предпринять лишь несколько базовых шагов, чтобы начать эффективно работать и наращивать мощность и продуктивность своей CRM-системы. Поговорим о них.

Чек-лист успешного старта CRM-системы

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

Учиться, учиться, ещё раз учиться

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

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

Рассказывает наш сотрудник: «Когда я пришёл работать в крупного интегратора решений VoIP, думал, что будет некомфортно — рабочее место должны были оборудовать в течение трёх дней. Мне не хотелось сидеть и видеть, как куча народу работает, а я разглядываю цветы на подоконнике или тыкаю в телефон. Однако я был избавлен от этого — мне сразу дали распечатки базовой информации о продукте, а потом подцепили планшет к внутренней сети и открыли крутой портал с информацией по всем вопросам — его создали сами сотрудники. Я потом тоже вписал туда не одну статью. Кстати, это была CRM, а не Jira. В ней же велись продажи, маркетинг и управление персоналом».  

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

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

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

Практика — first

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

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

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

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

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

Оперативная работа в CRM — привычка свыше нам дана

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

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

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

Да я жить без CRM не могу

Помните вот эту байку с Баша?



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

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

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

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

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

Ошибки, мешающие восприятию CRM-системы

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

1. Купили CRM по принципу «чем дороже, тем лучше». Как правило, в очень дорогих системах много лишних для СМБ функций, дорогое обучение, дорогая поддержка, сложная настройка. Дело не в цене, дело в том, насколько система отвечает потребностям вашего бизнеса.
   
2. Повелись на внедрение CRM за один день или две недели. Мы реально знаем вендоров, которые обещают любое внедрение за пару недель. Настройтесь на то, что это маркетинговая фишка — если вы морально приготовитесь к месяцу, а внедрение займёт три, вам покажется, что силы уже исчерпаны и пользование CRM-кой начнётся с недовольства.
   
3. Воспринимаете CRM как статичное хранилище данных и просто забиваете туда клиентов. Это неправильно — мы все уже давно ушли от контакт-менеджеров и предлагаем решения, которые делают работу быстрой и простой. Раз вы за это заплатили, зачем ходить пешком не стоит игнорировать такие возможности.
   
4. Вы избегаете CRM — вам кажется, что дела и так идут хорошо. Поверьте нашему опыту — это до первого увольнения ключевого сотрудника и до первого увода клиенсткой базы.
   

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


Собственно, вот вам и пример как раз шаблонного мышления менеджера

Мне ничего не помогло, CRM всё равно простаивает

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

CRM-систем сейчас много: новых и развитых, облачных, web, десктопных, дорогих и доступных, мощных и урезанных. В 1989 году в зарубежной прессе было всего одно упоминание CRM, сегодня это сотни тысяч запросов по всем миру. Жить без CRM-системы в 2017 году — откровенно, не самая лучшая идея, поскольку автоматизация давно стала конкурентным преимуществом. Стоит начать процесс внедрения, и вскоре вы поймёте, как менять процессы бизнеса, оптимизировать их, чтобы зарабатывать больше и работать продуктивнее. Дело-то за малым — начать.

P.S.: у нас идёт акция «Осеннее ускорение», так что если кому-то нужна скидка 15% на разный бизнес-софт (а мы делаем не только CRM-системы), то рады вам помочь, рассказать, провести бесплатную онлайн-презентацию — вы можете всё посмотреть и расспросить, не вставая с любимого кресла. Отвечаем даже на неудобные вопросы (по делу, конечно).

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

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

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

SecGen представляет из себя скрипт, написанный на ruby. В основе его работы лежат Vagrant и Puppet.

Напомню, что Vagrant — это инструмент, позволяющий быстро и удобно разворачивать целые инфраструктуры из виртуальных машин, используя гипервизоры VirtualBox, VM Ware локально или облачный сервис Amazon AWS. Вы можете описать все настройки будущей виртуальной машины в специальном файле Vagrantfile. И вам не придется скачивать ISO-образы ОС, т.к. Vagrant уже предлагает множество готовых образов виртуальных машин (box), которые можно скачать из специального каталога.

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

Таким образом SecGen нужно лишь выбрать какой box скачать и развернуть при помощи Vagrant, какой софт установить и настроить при помощи Puppet и сгенерировать флаги, которые нужно найти пентестеру в процессе эксплуатации.

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

Установка

Официально тестирование проводится на дистрибутиве Ubuntu и процесс установки описан на официальном github. Я буду использовать 64-битную Ubuntu 16.04.3, которая сама является виртуальной машиной с 2.5 ГБ RAM.

Устанавливаем требуемые пакеты

sudo apt-get install ruby-dev zlib1g-dev liblzma-dev build-essential patch virtualbox ruby-bundler vagrant imagemagick libmagickwand-dev exiftool

Также вам (возможно) потребуется установить еще один пакет, не указанный на официальном сайте

sudo apt-get install libpq-dev

Теперь клонируем репозиторий github

git clone https://github.com/cliffe/SecGen.git

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

cd SecGen
bundle install

Начнут устанавливаться необходимые библиотеки Ruby



Проверяем, что скрипт работает

ruby secgen.rb --help

И видим доступные опции

Создаем свою первую машину со случайным набором уязвимостей

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

ruby secgen.rb run

Начнется скачивание Vagrant box-а, который для нас автоматически выбрал SecGen



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



Автоматически настраивается форвард SSH для доступа к машине на порт 2222. Генерируется ключ, SecGen подключается к машине, устанавливает rsync и производит установку и настройку всего необходимого.



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

Будут выполнены все необходимые Puppet скрипты



И в конце концов вы увидите сообщение в консоли



И при помощи команды virtualbox можете убедиться, что машина действительно запущена

Анатомия

В каталоге SecGen, помимо прочих, есть директории projects, scenarios и modules.

Проекты

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

ruby secgen.rb --project home/user/SecGen/projects/SecGen20170920_1154 build-vms

Чтобы получить список проектов, нужно выполнить команду

ruby secgen.rb list-projects

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



Аналогично есть ключ build-project, задав который будут созданы конфигурационные файлы для Vagrant и Puppet, но виртуальные машины созданы не будут.

Сценарии

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

	
	
		storage_server
		

		
		

		

		
	

Здесь сказано, что будет создана виртуальная машина с ОС Linux, содержащая две уязвимости типов remote и local. Т.е. сначала нужно будет попасть на сервер через одну уязвимость и потом проэксплуатировать вторую локально.

Обычно из названия сценария становится ясно, какую машину создаст SecGen, например сценарий any_random_vulnerability.xml. Рекомендую ознакомиться с примерами в каталоге scenarios/examples.
Есть довольно сложные сценарии в каталогах scenarios/security_audit и scenarios/ctf.
Для CTF предлагается воспользоваться фронтендом от разработчиков SecGen.

Модули

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

• bases
• build
• encoders
• generators
• networks
• services
• utilities
• vulnerabilities

В свою очередь в каждой из групп есть подгруппы, вроде smb, webapp, bash, ftp и т.п.

Каждый модуль имеет примерно следующую структуру



Файл secgen_metadata.xml подробно описывает модуль. Это необходимо для корректной работы сценариев и выбора этого модуля для подходящего случая

Часть файла

  chkrootkit 0.49 privilege escalation
  Thomas Shaw
  MIT
  
    chkrootkit 0.49 and earlier contain a local privilege escalation vulnerability allowing a non-root user to place a
    script in /tmp that will be executed as root when chkrootkit is run. This module adds a cronjob to run chkrootkit
    periodically for exploitability.
  

  privilege_escalation
  root_rwx
  local
  linux
...

Каталог manifes содержит puppet скрипты configure.pp, init.pp и install.pp
Каталог files содержит необходимые дистрибутивы. В данном случае один файл chkrootkit-0.49.tar.gz

Детали проекта

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

Например в нашем проекте мы можем найти два XML тега vulnerability, указывающие на модули
modules/vulnerabilities/unix/misc/distcc_exec с описанием «Distcc has a documented security weakness that enables remote code execution» и modules/vulnerabilities/unix/desktop/xfce_lightdm_root_login с описанием «Configures XFCE w/ LightDM to automatically login as root without a password\.»

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

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

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

ssh vagrant@127.0.0.1 -p 2222 -i private_key

команда ifconfig выдаст нам следующий результат

eth0      Link encap:Ethernet  HWaddr 08:00:27:86:1c:fb  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe86:1cfb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:125254 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13570 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:177651061 (169.4 MiB)  TX bytes:1034124 (1009.8 KiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:83:ea:5e  
          inet addr:172.28.128.3  Bcast:172.28.128.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe83:ea5e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3130 (3.0 KiB)  TX bytes:2304 (2.2 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Тестируем

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



Сканируем и обнаруживаем следующие открытые порты

sudo nmap -n -Pn -p- 172.28.128.3

Далее при помощи вашего любимого дистрибутива для тестирования на проникновение можно начинать эксплуатацию distcc.

В заключении

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

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

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

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

SecGen представляет из себя скрипт, написанный на ruby. В основе его работы лежат Vagrant и Puppet.

Напомню, что Vagrant — это инструмент, позволяющий быстро и удобно разворачивать целые инфраструктуры из виртуальных машин, используя гипервизоры VirtualBox, VM Ware локально или облачный сервис Amazon AWS. Вы можете описать все настройки будущей виртуальной машины в специальном файле Vagrantfile. И вам не придется скачивать ISO-образы ОС, т.к. Vagrant уже предлагает множество готовых образов виртуальных машин (box), которые можно скачать из специального каталога.

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

Таким образом SecGen нужно лишь выбрать какой box скачать и развернуть при помощи Vagrant, какой софт установить и настроить при помощи Puppet и сгенерировать флаги, которые нужно найти пентестеру в процессе эксплуатации.

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

Установка

Официально тестирование проводится на дистрибутиве Ubuntu и процесс установки описан на официальном github. Я буду использовать 64-битную Ubuntu 16.04.3, которая сама является виртуальной машиной с 2.5 ГБ RAM.

Устанавливаем требуемые пакеты

sudo apt-get install ruby-dev zlib1g-dev liblzma-dev build-essential patch virtualbox ruby-bundler vagrant imagemagick libmagickwand-dev exiftool

Также вам (возможно) потребуется установить еще один пакет, не указанный на официальном сайте

sudo apt-get install libpq-dev

Теперь клонируем репозиторий github

git clone https://github.com/cliffe/SecGen.git

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

cd SecGen
bundle install

Начнут устанавливаться необходимые библиотеки Ruby



Проверяем, что скрипт работает

ruby secgen.rb --help

И видим доступные опции

Создаем свою первую машину со случайным набором уязвимостей

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

ruby secgen.rb run

Начнется скачивание Vagrant box-а, который для нас автоматически выбрал SecGen



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



Автоматически настраивается форвард SSH для доступа к машине на порт 2222. Генерируется ключ, SecGen подключается к машине, устанавливает rsync и производит установку и настройку всего необходимого.



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

Будут выполнены все необходимые Puppet скрипты



И в конце концов вы увидите сообщение в консоли



И при помощи команды virtualbox можете убедиться, что машина действительно запущена

Анатомия

В каталоге SecGen, помимо прочих, есть директории projects, scenarios и modules.

Проекты

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

ruby secgen.rb --project home/user/SecGen/projects/SecGen20170920_1154 build-vms

Чтобы получить список проектов, нужно выполнить команду

ruby secgen.rb list-projects

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



Аналогично есть ключ build-project, задав который будут созданы конфигурационные файлы для Vagrant и Puppet, но виртуальные машины созданы не будут.

Сценарии

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

	
	
		storage_server
		

		
		

		

		
	

Здесь сказано, что будет создана виртуальная машина с ОС Linux, содержащая две уязвимости типов remote и local. Т.е. сначала нужно будет попасть на сервер через одну уязвимость и потом проэксплуатировать вторую локально.

Обычно из названия сценария становится ясно, какую машину создаст SecGen, например сценарий any_random_vulnerability.xml. Рекомендую ознакомиться с примерами в каталоге scenarios/examples.
Есть довольно сложные сценарии в каталогах scenarios/security_audit и scenarios/ctf.
Для CTF предлагается воспользоваться фронтендом от разработчиков SecGen.

Модули

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

• bases
• build
• encoders
• generators
• networks
• services
• utilities
• vulnerabilities

В свою очередь в каждой из групп есть подгруппы, вроде smb, webapp, bash, ftp и т.п.

Каждый модуль имеет примерно следующую структуру



Файл secgen_metadata.xml подробно описывает модуль. Это необходимо для корректной работы сценариев и выбора этого модуля для подходящего случая

Часть файла

  chkrootkit 0.49 privilege escalation
  Thomas Shaw
  MIT
  
    chkrootkit 0.49 and earlier contain a local privilege escalation vulnerability allowing a non-root user to place a
    script in /tmp that will be executed as root when chkrootkit is run. This module adds a cronjob to run chkrootkit
    periodically for exploitability.
  

  privilege_escalation
  root_rwx
  local
  linux
...

Каталог manifes содержит puppet скрипты configure.pp, init.pp и install.pp
Каталог files содержит необходимые дистрибутивы. В данном случае один файл chkrootkit-0.49.tar.gz

Детали проекта

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

Например в нашем проекте мы можем найти два XML тега vulnerability, указывающие на модули
modules/vulnerabilities/unix/misc/distcc_exec с описанием «Distcc has a documented security weakness that enables remote code execution» и modules/vulnerabilities/unix/desktop/xfce_lightdm_root_login с описанием «Configures XFCE w/ LightDM to automatically login as root without a password\.»

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

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

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

ssh vagrant@127.0.0.1 -p 2222 -i private_key

команда ifconfig выдаст нам следующий результат

eth0      Link encap:Ethernet  HWaddr 08:00:27:86:1c:fb  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe86:1cfb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:125254 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13570 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:177651061 (169.4 MiB)  TX bytes:1034124 (1009.8 KiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:83:ea:5e  
          inet addr:172.28.128.3  Bcast:172.28.128.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe83:ea5e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3130 (3.0 KiB)  TX bytes:2304 (2.2 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Тестируем

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



Сканируем и обнаруживаем следующие открытые порты

sudo nmap -n -Pn -p- 172.28.128.3

Далее при помощи вашего любимого дистрибутива для тестирования на проникновение можно начинать эксплуатацию distcc.

В заключении

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

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

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

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




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

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

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

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

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

Какие же исследования легли в основу нового учебного формата, названного нами «Персональное обучение»?

Научим всех и каждого

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


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

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


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

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


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

Источник

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



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

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

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

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



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

Впрочем, идея только выглядит простой, но ее реализация «в лоб» приведет к катастрофе. Даже самое интересное видео невозможно смотреть долго, совсем не прерываясь. Поэтому нельзя показывать студентам полную запись выступления преподавателя в течение 45 минут. А у нас курс длится 5 дней по 8 часов!

Как усвоить и не забыть – боремся с человеческой природой

Источник

На эффективность усвоения материала сильно влияет, через какие органы чувств человек воспринимает информацию. Если учащийся читает книгу, он в состоянии воспринять не более 8% материала. Видеофильм увеличивает долю усвоенного материала до 40%. Проговаривание новой темы позволяет овладеть 60% информации. Если человек обсудит новый материал и применит его на практике, он усвоит до 80% информации.


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

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



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

Давайте посмотрим на график посещаемости одного из курсов Coursera на протяжении всего времени, когда он был доступен. Как думаете, с чем связаны периодические пики посещаемости?



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

Дафна Коллер, одна из основателей Coursera, комментируя график, сделала замечательный вывод: «Мы доказали, что во всем мире откладывание дел на последний момент – самая популярная стратегия поведения».

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

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

Источник

Как можно хотя бы попытаться побороть забывчивость?

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



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

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

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

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

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



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

Как же бороться с быстрым забыванием?

Чтобы информация, например, от 45-минутного занятия осталась у вас в голове если не навсегда, то надолго, нужно через день повторить ее в течение 10 минут, через неделю потратить на это 5 минут, через месяц – 2-4 минуты. Еще раз повторим (простите за каламбур), что повторить – это значит попытаться активно вспомнить материал. Не прочитать еще раз, а именно вспомнить.



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

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

Большой выбор интерактивных образовательных материалов – это прекрасно. Или нет?

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

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



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

А как вы думаете, у какого столика дегустация приводила к большему количеству покупок варенья? Как ни странно, покупок у столика с бОльшим выбором было в десять раз (!) меньше. Все потому, что выбор вгонял людей в ступор и они не могли определиться со своими желаниями. Какой из 24 вкусов предпочесть?

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

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

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

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

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



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

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

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

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

Персональное обучение в цифрах

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

На основе их ответов мы сделали график, показывающий:

• субъективный прогресс в знаниях – если до курсов человек оценил свои знания на один балл, а после – на десять, значит, его прогресс составит девять баллов;
  
• объективный результат оценки знаний в ходе тестирования (max – 100%);
  
• впечатления от преподавателей (max — 5 баллов);
  
• впечатления о работе оборудования учебного центра (max — 5 баллов).
  

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

Выпускники курсов в формате персонального обучения в два раза выше оценивают собственный прогресс по сравнению с учащимися самой эффективной очной формы. Конечно, оценки субъективны – люди могут многое насочинять. Однако эти выпускники действительно лучше сдают экзамены-тесты – разница составляет 30%!

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

Когда все слишком хорошо, это тоже немножко плохо

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

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


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

Один из учителей поясняет: «Источник жизненной силы любого класса – дискуссия, а для ее ведения необходима определенная критическая масса. В настоящее время я работаю с классами, где есть ученики, которые вообще никогда не участвуют в обсуждениях, это кошмар какой-то. Если учеников слишком мало, обсуждение тоже страдает. Кажется нелогичным, ведь я всегда считал, что робкие дети, которым неловко выступать в классе из 32 учеников, охотнее разговорятся в классе из 16 человек. Но я ошибался. Робкие дети робели вне зависимости от размера класса. А если класс слишком маленький, то среди участников не наблюдается широкого разброса мнений, необходимых, чтобы дискуссия развивалась. К тому же очень маленькая группа лишена той энергии, что возникает в результате трений между людьми».
(Гладуэлл Малкольм «Давид и Голиаф. Как аутсайдеры побеждают фаворитов» )

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

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

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

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

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

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

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




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

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

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

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

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

Какие же исследования легли в основу нового учебного формата, названного нами «Персональное обучение»?

Научим всех и каждого

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


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

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


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

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


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

Источник

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



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

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

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

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



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

Впрочем, идея только выглядит простой, но ее реализация «в лоб» приведет к катастрофе. Даже самое интересное видео невозможно смотреть долго, совсем не прерываясь. Поэтому нельзя показывать студентам полную запись выступления преподавателя в течение 45 минут. А у нас курс длится 5 дней по 8 часов!

Как усвоить и не забыть – боремся с человеческой природой

Источник

На эффективность усвоения материала сильно влияет, через какие органы чувств человек воспринимает информацию. Если учащийся читает книгу, он в состоянии воспринять не более 8% материала. Видеофильм увеличивает долю усвоенного материала до 40%. Проговаривание новой темы позволяет овладеть 60% информации. Если человек обсудит новый материал и применит его на практике, он усвоит до 80% информации.


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

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



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

Давайте посмотрим на график посещаемости одного из курсов Coursera на протяжении всего времени, когда он был доступен. Как думаете, с чем связаны периодические пики посещаемости?



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

Дафна Коллер, одна из основателей Coursera, комментируя график, сделала замечательный вывод: «Мы доказали, что во всем мире откладывание дел на последний момент – самая популярная стратегия поведения».

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

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

Источник

Как можно хотя бы попытаться побороть забывчивость?

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



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

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

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

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

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



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

Как же бороться с быстрым забыванием?

Чтобы информация, например, от 45-минутного занятия осталась у вас в голове если не навсегда, то надолго, нужно через день повторить ее в течение 10 минут, через неделю потратить на это 5 минут, через месяц – 2-4 минуты. Еще раз повторим (простите за каламбур), что повторить – это значит попытаться активно вспомнить материал. Не прочитать еще раз, а именно вспомнить.



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

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

Большой выбор интерактивных образовательных материалов – это прекрасно. Или нет?

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

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



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

А как вы думаете, у какого столика дегустация приводила к большему количеству покупок варенья? Как ни странно, покупок у столика с бОльшим выбором было в десять раз (!) меньше. Все потому, что выбор вгонял людей в ступор и они не могли определиться со своими желаниями. Какой из 24 вкусов предпочесть?

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

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

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

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

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



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

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

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

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

Персональное обучение в цифрах

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

На основе их ответов мы сделали график, показывающий:

• субъективный прогресс в знаниях – если до курсов человек оценил свои знания на один балл, а после – на десять, значит, его прогресс составит девять баллов;
  
• объективный результат оценки знаний в ходе тестирования (max – 100%);
  
• впечатления от преподавателей (max — 5 баллов);
  
• впечатления о работе оборудования учебного центра (max — 5 баллов).
  

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

Выпускники курсов в формате персонального обучения в два раза выше оценивают собственный прогресс по сравнению с учащимися самой эффективной очной формы. Конечно, оценки субъективны – люди могут многое насочинять. Однако эти выпускники действительно лучше сдают экзамены-тесты – разница составляет 30%!

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

Когда все слишком хорошо, это тоже немножко плохо

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

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


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

Один из учителей поясняет: «Источник жизненной силы любого класса – дискуссия, а для ее ведения необходима определенная критическая масса. В настоящее время я работаю с классами, где есть ученики, которые вообще никогда не участвуют в обсуждениях, это кошмар какой-то. Если учеников слишком мало, обсуждение тоже страдает. Кажется нелогичным, ведь я всегда считал, что робкие дети, которым неловко выступать в классе из 32 учеников, охотнее разговорятся в классе из 16 человек. Но я ошибался. Робкие дети робели вне зависимости от размера класса. А если класс слишком маленький, то среди участников не наблюдается широкого разброса мнений, необходимых, чтобы дискуссия развивалась. К тому же очень маленькая группа лишена той энергии, что возникает в результате трений между людьми».
(Гладуэлл Малкольм «Давид и Голиаф. Как аутсайдеры побеждают фаворитов» )

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

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

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

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

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

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

Задумаемся на секунду, что нужно для системы электронного управления? Сервопривод, который может поворачивать колёса, и контроллер, чтобы сервоприводом управлять. Внезапно, всё это в большинстве современных автомобилей уже есть, и называется "усилитель рулевого управления". Традиционные чисто механические (как правило, гидравлические) усилители стремительно исчезают с рынка, уступая место узлам с электронным блоком управления (ЭБУ). А значит, задача сразу упрощается: нам остается только "уговорить" имеющийся ЭБУ усилителя выдать нужные команды на сервопривод.

Очень удобным для доработки оказался KIA Cee'd начиная с 2015 модельного года (скорее всего аналогично и его соплатформенники от KIA/Hyundai). Сошлись одновременно несколько факторов:

• Усилитель руля полностью электрический, нет возни с гидравликой, стоит копейки (относительно) на разборках. Вся нужная проводка выведена наружу и легко доступна.
• Усилитель интегрирован с рулевой колонкой, поэтому к нему есть легкий доступ на автомобиле и любая дополнительная электроника останется в салоне в тепличных условиях (в отличие от усилителей, интегрированных в рулевую рейку).
• Очень важно — есть пример успешной доработки аналогичного KIA Soul. Американская PolySync разрабатывает апгрейд Soul до полностью drive-by-wire платформы для беспилотников, и на их гитхабе можно подсмотреть много полезного.

Итак, получена в распоряжение рулевая колонка в сборе:

Будем заставлять её крутиться. Для этого нужно создать у блока управления впечатление, что

1. Он находится в автомобиле с работающим двигателем.
2. Водитель прикладывает вращающее усилие к рулевому колесу.

Пойдем по порядку.

Симуляция автомобиля

Нужно понять интерфейс между электронным блоком управления (ЭБУ) усилителя и остальным автомобилем. Нагуглив электрическую схему видим картинку:

Из схемы видно, что физически интерфейс очень прост:

• Питание (12V постоянное) через разъем E29.
• Сигнал включенного зажигания (12V) через разъем M46.
• CAN-шина данных также через разъем M46.

Внешний вид и распиновки разъемов находим на том же сайте.

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

Обмен данными между электронными блоками в современных автомобилях организован по шинам CAN (Controller Area Network). Это широковещательная (у пакетов нет адресов назначения) локальная сеть на витой паре, где каждый блок может публиковать свои данные. У каждого типа данных свой идентификатор. Например, в нашем случае усилитель руля рассылает значения угла поворота руля с ID 0x2B0. Часто бывает несколько физически разделенных шин, чтобы второстепенные блоки типа контроллеров стеклоподъемников не мешались обмену между критически важными компонентами. В Cee'd используется две шины: C-CAN и B-CAN (схема здесь, в части "Информация о канале передачи данных"). На C-CAN "висят" почти все блоки с ней и будем работать.

Выбор адаптера CAN-шины

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

1. Адаптеры в сборе с алиэкспресса. Их не пробовал, по слухам довольно много брака и софт видимо только под Windows.
2. Arduino шилды на MCP2515/MCP2551, в основном клоны дизайна от seeed в любом магазине ардуинной тематики. Но совмещать такой шилд надо не с Arduino (я так и не смог заставить связку работать на воспроизведение с нужной скоростью), а с Raspberry Pi. В приложении ниже подробная инструкция.
3. USB адаптер CANHacker Baby, разработка Artemka86. Выгодно отличается от вариантов с алиэкспресса отличной поддержкой "из первых рук" от разработчика (проверено лично, Артём подходит к делу с душой). Также плюсом является поддержка стандартного протокола LAWICEL совместимого с широким набором софта.

Софта разного тоже много (за обзором опять сюда). Самый простой вариант — Linux c can-utils из SocketCAN, за который спасибо инженерам Volkswagen. Большой плюс SocketCAN в стандартизации — любое USB устройство с поддержкой протокола LAWICEL (pdf) видится системой как обычный сетевой интерфейс. Таким образом избегаем привязки к вендор-специфическому софту конкретного устройства. У текущей версии CANHacker есть небольшая несовместимость со стоковыми can-utils по работе с USB, поэтому берём патченную версию отсюда. Raspberry Pi с CAN шилдом работает со стоковым пакетом can-utils из Raspbian OS без проблем.

Подключение к шине, запись пакетов

С подключением к индивидуальному узлу на стенде всё просто: соединяем контакт CAN-High адаптера с CAN-High автомобильного узла, CAN-Low — c CAN-Low. По стандарту между CAN-High и CAN-Low должно быть 2 замыкающих резистора по 120 Ом, на практике обычно всё работает на довольно широком интервале сопротивлений, у меня например одно на 110 Ом.

На автомобиле замыкающий резистор не нужен (они там уже стоят, чтобы шина сама по себе работала). В зависимости от модели авто, возможно придется повозиться с физическим доступом к проводке шины. Самый удобный вариант — разъём OBD-II (on-board diagnostic), он обязателен на всех легковых автомобилях, выпущенных в Европе с начиная 2001-2004 года и находится не дальше 60 см от рулевого колеса. На Cee'd разъём слева под рулём, за пластмасовой крышкой блока предохранителей.

Распиновка OBD-II стандартизована и включает шину CAN (CANH на 6 контакте, CANL на 14). Нам повезло, корейцы пошли по пути наименьшего сопротивления и вывели C-CAN, на которой висят все важные узлы, прямо на диагностический разъём:

В результате на Cee'd можно прослушать весь внутренний трафик, ничего в авто не разбирая. Когда машина не твоя, а знакомые пустили повозиться — большой плюс. Но такая халява не везде. У Volkswagen например служебная CAN изолирована от OBD шлюзом, поэтому подключаться пришлось бы примерно так:

Подключив все контакты, поднимаем сетевой интерфейс:

$ sudo slcand -o -c -s6 -S 115200 ttyACM0 slcan0 && sleep 1 && sudo ifconfig slcan0 up

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

$ cansniffer slcan0

И наконец, если всё нормально, можно записывать лог:

$ candump -L slcan0 > real-car-can-log.txt

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

Воспроизведение записи шины на стенде

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

$ $ candump slcan0
  slcan0  2B0   [5]  00 00 00 00 00
  slcan0  2B0   [5]  FF 7F FF 06 F1
  slcan0  2B0   [5]  FF 7F FF 06 C2
  slcan0  2B0   [5]  FF 7F FF 06 D3
  slcan0  2B0   [5]  FF 7F FF 06 A4
  slcan0  2B0   [5]  FF 7F FF 06 B5
  slcan0  2B0   [5]  FF 7F FF 06 86
  slcan0  2B0   [5]  FF 7F FF 06 97
  slcan0  2B0   [5]  FF 7F FF 06 68
  slcan0  5E4   [3]  00 00 00
  slcan0  2B0   [5]  FF 7F FF 06 79
  slcan0  2B0   [5]  FF 7F FF 06 4A
....

Видим, что рассылаются пакеты 2B0 (текущий угол поворота руля) и, реже, 5E4 (какой-то общий статус усилителя). Отфильтровываем их из общего лога:

$ cat real-car-can-log.txt | grep -v ' 2B0' | grep -v ' 5E4 ' > can-log-no-steering.txt

Фильтрованный лог можно подавать на воспроизведение:

% sudo ifconfig slcan0 txqueuelen 1000
$ canplayer -I can-log-no-steering.txt

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

Эмуляция усилия на руле

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

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

Проверка формата сигнала датчиков

По информации PolySync, на Soul, у которого с Cee'd общая платформа, два аналоговых датчика крутящего момента. Cигнал каждого — отклонение уровня постоянного напряжения от базовых 2.5V, провода в жгуте — зеленый и синий. Проверим, что у нас то же самое:

• Размыкаем разъем на ЭБУ, пробрасываем нужные контакты через макетку и заводим на аналоговые входы arduino.
  
• Загружаем скетч, в цикле замеряющий напряжения и печатающий их в терминал.
• Запускаем Serial Plotter в Arduino IDE, поворачиваем рулевой вал. Видим результат на графике, схема совпадает с Soul:
  
• Радуемся сэкономленному времени.

Эмуляция сигнала датчиков

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

Нужно добавить к arduino внешние ЦАП/АЦП. Мне попались модули YL-40 (описание в pdf) на основе чипа PCF8591 — на каждой по 4 канала 8-бит АЦП и 1 8-бит ЦАП. Модуль может общаться с arduino по протоколу I2C. Потребуется небольшое допиливание (в буквальном смысле): китайские товарищи поставили на плату светодиод индикации напряжения на выходе ЦАП — его обязательно надо отсоединить. Иначе утекающий через диод ток не даст ЦАП поднять напряжение на выходе больше 4.2V (вместо штатных 5V). Диод отсоединяем, отковыривая резистор R4 с обратной стороны платы.

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

С интерфейсом к arduino есть нюанс — нам нужно 2 канала ЦАП, соотвественно 2 модуля, но у них одинаковые адреса I2C (зашиты в чип). Хотя чип позволяет менять свой I2C адрес, замыкая определенные ноги на +5V вместо земли, на плате эти перемычки не разведены. Вместо перепайки возьмем костыль — две разные библиотеки I2C на arduino (стандартная Wire и SoftI2CMaster), каждая на свою пару пинов. Получаем модули на разных шинах, конфликт пропадает.

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

1. Включаем arduino, открываем Serial Monitor. Важно запустить arduino первой, не останавливать и не прерывать. Иначе напряжение на выходах ЦАПов сбросится, ЭБУ усилителя определит ошибку сигнала с датчиков, уйдет в безопасный редим и придется все перезапускать по новой.
2. Запитываем усилитель, подключаем зажигание.
3. Запускаем воспроизведение лога CAN-шины.
4. Теперь по командам l и r через Serial Monitor усилитель будет поворачивать рулевой вал. Объявляется победа.

На сегодня всё, на очереди доработка софта (интеграция с CAN шиной, чтение оттуда текущего угла поворота и динамическое управление крутящим усилием, чтобы внешний контроллер мог задать фиксированный угол поворота руля и система его выдерживала), отработка на автомобиле (на стенде не смоделируешь сопротивление от колёс). Возможно замена 8-битных ЦАП/АЦП на 10 или 12 бит (взял первое, что под руку попалось). Рулящая нейросеть тоже в процессе, надеюсь скоро сделать пост.

Спасибо Artemka86 за ценные консультации по работе с CAN и помощь с оборудованием.

Ресурсы для дальнейшего погружения

1. Car Hacking: The definitive source. Начинать можно с Car Hacking for Poories, там отлично покрыты основы. Остальное тоже интересно, но с упором на несанкционированный доступ.
2. The Car Hacker's Handbook: A Guide for the Penetration Tester. Больше деталей, чем в Car Hacking: The definitive source, тоже акцент на несанкционированный доступ. Если читать как первое введение в тему, надо приспособиться пропускать большие куски.
3. Car Hacking 101: Tools of the Trade, MCD Software — обзоры инструментов. В основном малоинтересная экзотика на мой взгляд.
4. Open Source Car Control — открытая платформа для KIA Soul, в процессе разработки. Они делают полное решение (руль, акселератор, тормоза), включвя доработки по "железу" на машине (в основном для тормозов — ставятся дополнительные тормозные приводы, что-то меняется в тормозной гидравлике итд). Релиза ещё не было, но многие вещи уже можно подсмотреть.

Бонус. Совмещаем Raspberry Pi и Arduino CAN shield

Прежде всего, внимание, CAN шилд и raspberry pi нельзя соединять напрямую, они не совместимы по напряжению. На Arduino UNO-совместимых платах напряжение логики 5V, а на raspberry pi только 3.3V, поэтому прямое соединение только сожжет задействованные пины.

Нам понадобятся:

• Raspberry Pi (проверялось на версии 3B).
• Arduino CAN шилд на MCP2515/MCP2551.
• Преобразователь уровня логики на 5 каналов или больше (можно 2 по 4 канала, но понадобится больше соединений). Мне попался этот

Нужно завести на CAN шилд питание (5V), соединения интерфейса данных SPI (4 пина: MOSI, MISO, SCLK, CS) и 1 пин сигнала прерывания. Всё, кроме питания, идет через преобразователь уровня, который в свою очередь тоже надо запитать.

На схемах ищем нужные пины.

Raspberry Pi:

CAN шилд:

Получаем результат:

• SPI на raspberry pi 19, 21, 23, 24 (MOSI, MISO, SCLK, CS) соответствуют D11, D12, D13, D9 (или на некоторых версиях D10) на CAN шилде.
• Прерывание с D2 на шилде можно завести на любой GPIO пин raspberry, у меня это пин 22 (GPIO 25). Номер пина укажем в софте при настройке.

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

Всё, кроме 5V питания и земли на шилд идёт через преобразователь:

Переходим к настройке софта (стандартный Raspbian).

1. Включаем поддержку SPI и CAN модуля. В /boot/config.txt добавляем

   
   

   dtparam=spi=on
   dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25,spimaxfrequency=1000000
   dtoverlay=spi0-hw-cs

   
   

   Здесь interrupt=25 указывает пин, на который заведено прерывание с шилда. Индексация идёт по GPIO пинам, поэтому interrupt=25 это GPIO 25, он же пин 22 по сквозной индексации всех пинов. Также важно указать частоту интерфейса SPI spimaxfrequency, т.к. значение по умолчанию — 10 МГц — слишком высокое для шилда, он просто не соединится.

   
   

2. Перезагружаем raspberry pi, проверяем соединение с шилдом:

   
   

   $ dmesg
   ...
   [   12.985754] CAN device driver interface
   [   13.014774] mcp251x spi0.0 can0: MCP2515 successfully initialized.
   ...

   
   

3. Устанавливаем can-utils:

   
   

   $ sudo apt install can-utils

   
   

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

   
   

   $ sudo /sbin/ip link set can0 up type can bitrate 500000
   $ sudo ifconfig can0 txqueuelen 1000

   
   

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

   
   
5. Готово, можно пользоваться candump, cansniffer и всем остальным из can-utils.

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