Мы продолжаем беседу со специалистами компании Percona. Материал получился очень интересный. На наши вопросы ответил Пётр Зайцев, основатель и CEO компании. Послужной список Петра велик: создание и развитие крупнейшего консалтинга, занимающегося поддержкой и обслуживанием решений на базе MySQL и MongoDB; соавторство опубликованной издательством O’Reilly книги «MySQL. Оптимизация производительности»; регулярные публикации в Percona Database Performance Blog, один из лучших технических блогов, посвященных MySQL и PostgreSQL. Незадолго до основания собственной компании, Петр возглавлял группу оптимизации производительности (High Performance Group) в MySQL AB.

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

На PG Day'17 Russia Петр впервые прочитает для русскоязычной аудитории свой авторский курс, посвященный архитектуре и оптимизации производительности InnoDB, а также проведет обзор доступных средств для эксплуатации MySQL 5.7 как документо-ориентированной базы данных.



PG Day: Пётр, расскажи о себе, кто ты и чем ты занимаешься?

Петр: Петр Зайцев – основатель и СЕО компании “Перкона” (Percona). Компания была основана более 10 лет назад. Мы предоставляем решения в сфере MySQL и MongoDB. Основной наш бизнес – это поддержка (support), удаленное администрирование (remote DBA) и управление (managed services), но мы также занимаемся консалтингом и тренингами.

PG Day: Как вы начали строить бизнес именно вокруг MySQL? Почему выбрали эту СУБД?

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

PG Day: Когда ты еще работал в MySQL AB, у тебя был технический бэкграунд, то есть ты пришел в менеджмент из технологий?

Петр: Да, верно. В MySQL я работал в чисто технической роли. Последний год я был entry-level менеджером. Но, в основном, это было техническое направление.

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

Петр: Здесь есть несколько критериев. Я считаю, что с MySQL мне очень сильно повезло по двум причинам. Во-первых, когда “Перкона” была основана, рынок MySQL очень быстро рос, не хватало специалистов, и многие компании, которые хотели внедрять эту технологию, были готовы платить очень много денег. Такие циклы повторяются и для других технологий. Например, Hadoop. Несколько лет назад, когда произошел взрывной рост Hadoop, у людей, которые понимали в этой технологии, были очень хорошие возможности, потому что спрос превышал предложение в разы. Сейчас я бы, конечно, смотрел на это направление. И второе, один из ключевых моментов успеха — важно делать то, что тебе нравится, то, к чему у тебя лежит душа. Если ты занимаешься тем, что тебе не нравится, просто ради денег, то вряд ли будет успех, в какой бы области ты ни работал.

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

Петр: Рынок закрытого программного обеспечения или даже открытых исходников основной функциональности (open core) с некоторыми платными фичами значительно больше, чем рынок полностью открытого программного обеспечения, которым занимается “Перкона”. Тем не менее, на нем также есть очень много конкурирующих компаний. В этот рынок вкладывается очень много ресурсов, компании поднимают много денег — венчурные капиталы и т.д. У них совершенно другая бизнес-модель, которая нам не очень интересна.

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

Часто люди, говоря о рынке “Перконы”, сравнивают нас с кем-то вроде MongoDB, MySQL или MariaDB. На самом деле это не совсем правильно, потому что наша задача не создать платформу или технологию с нуля, а предоставлять услуги для лучшей открытой платформы в этой области. Если бы мы делали Percona Server с закрытыми “примочками”, то разница между нашим решением и, например, решениями Oracle, была бы очень мала. Это был бы тот же самый Oracle, но попроще, подешевле. Это не очень хороший мотиватор. Если удел Oracle – это закрытое программное обеспечение, которое делает пользователей зависимыми от поставщика (vendor lock-in), даже в случае с MySQL – это open core, то мы делаем Open Source, который помогает избежать этого. Очень понятная и простая разница.

PG Day: Как с того момента, как ваша компания была основана, развился рынок поддержки, консалтинга MySQL? Наверняка у “Перконы” стало больше конкурентов. Чем вы от них отличаетесь? Что позволяет вам оставаться конкурентоспособными и занимать высокие позиции на рынке?

Петр: Если говорить о MySQL, “Перкона” работает на нескольких рынках, которые имеют разных конкурентов. Если говорить о поддержке, то компании, которые являются нашими конкурентами – это только Oracle и MongoDB, две единственные компании, которые реально могут предоставлять полный цикл поддержки, включая исправление проблем, багов в программном обеспечении. MariaDB тоже была на рынке MySQL, но сейчас они выходят с него и фокусируются только на поддержке платформы MariaDB.

Мы уникальны тем, что являемся единственной компанией, которая поддерживает широкий спектр MySQL и MongoDB технологий, а не только свои решения. Например, если MySQL от Oracle поддерживает свой стек технологий для бэкапа, мониторинга и всего остального, то мы поддерживаем как наши технологии Percona Server, Percona XtraDB Cluster, так и MySQL от Oracle, вариант MySQL от MariaDB, а также облачные решения — такие, как Amazon RDS и Google Cloud SQL.

В области поддержки мы являемся единственным вендором, который покрывает и MySQL, и MongoDB одновременно, что многим достаточно интересно по двум причинам. Во-первых, когда происходит эволюция технологий, во многих компаниях образуется баланс между тем, сколько MySQL и сколько MongoDB они используют. Достаточно сложно работать с двумя вендорами, это негибко и неудобно. Если “взлетит” цена на услуги Oracle, вы скажете: «Слушайте, ребята. Мы у вас купили поддержку для 100 MySQL instances, но на самом деле мы будем использовать 50 экземпляров MySQL, а остальные будут MongoDB. Можем мы перевести лицензии?». Конечно, они скажут: «Не можете», — потому что они будут получать меньше денег. С нашей стороны, мы предоставляем поддержку, которая покрывает оба решения, а сколько чего клиент предполагает использовать, остается на его усмотрение.

Во-вторых, любой вендор, который работает только с одной технологией, заинтересован в том, чтобы эта технология использовалась как можно больше. Чем больше ты сможешь показать, что MySQL может использоваться, тем больше договоров на поддержку ты можешь получить. На текущем этапе, если есть выбор между этими двумя СУБД, у нас нет такой мотивации. Клиент может использовать MySQL или MongoDB — для нас это не имеет финансовой разницы. Это позволяет всей нашей команде предлагать более объективные решения, которые основаны на выгодах для клиента, и избегать конфликта интересов. Наверное, одна из наиболее важных вещей, которые легли в основу “Перконы”: мы стараемся концентрироваться на решении, которое действительно является оптимальным клиента, а не для нашего кошелька.

В сфере удаленного управления и администрирования конкуренты у нас уже другие: такие компании, как Pythian и Datavail. И также “облачные” компании, потому что владельцы многих бизнесов сейчас начинают думать: “Если я буду использовать Database as a Service, облачные решения от Amazon, Google Cloud SQL, то, может, мне DBA и не нужны будут?” Для многих компаний это не совсем так, но этот вариант конкуренции тоже является интересным кейсом для нас. Но если говорить в целом о наших сервисах, самый большой конкурент – это, наверное, те, кто делают все самостоятельно. Я это часто объясняю на примере рынка уборки в офисе. Кто здесь самый большой конкурент? Возможно, многие скажут: «А давайте мы сэкономим деньги, сами будем убирать и пылесосить!» Понятно, что это своего рода выбор. И такой выбор стоит перед людьми, которые решают, самим управлять своими базами данных или отдать их кому-то другому.

PG Day: Ты упомянул про сервис удаленного администрирования. Я так понимаю, это DBA-специалисты, которые работают как внешние подрядчики для компаний, оказывают услуги консалтинга. Можешь рассказать, как вы пришли к такому направлению, чем оно привлекательно сейчас?

Петр: Во-первых, мы предпочитаем об этом говорить не как о внешнем подряде, который часто ассоциируется с чем-то негативным. Мы чаще говорим о продолжении облачной модели и технологий типа “Х as a service”. Что у нас происходит с облаком? Люди поняли, что очень часто не имеет смысла нанимать и содержать полный штат специалистов, которые могут поставить серверы и подключить кабели. Для многих компаний это не слишком критичные решения, их можно отдать на аутсорс, чтобы компания могла сфокусироваться на своем основном бизнесе.

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

В этом плане рынок Database as a Service нам даже помогает, потому что эти компании вкладывают много средств в маркетинг. Они стараются донести до клиентов мысль о том, что самим настраивать базы данных и управлять ими может быть невыгодно. Но они не идут до конца. Если посмотреть, например, на Amazon RDS, то это не тот сервис, с которым может работать менеджер. Кто-то должен решать, какие instances нужно развернуть, как “задизайнить” схему. Простая настройка бэкапа, мониторинга тоже требует наличия технических специалистов. И это как раз то, что мы можем предложить, потому что мы умеем становиться частью команды и сотрудничать непосредственно и с менеджментом, и с отделом разработки для того, чтобы полностью решить эти проблемы.

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

Петр: С одной стороны, мы в начале разработки своей стратегии хотели добавить еще технологии. Я считаю очень важным, чтобы мы действительно могли представлять объективные решения клиентам. Есть такая пословица: if you have a hammer, everything looks like a nail — если у тебя есть один инструмент, которым ты умеешь работать, то тебе все кажется подходящим для этого инструмента, даже когда он не нужен. Появилась возможность на рынке MongoDB, и она очень хорошо подошла для нас: на этом рынке имеется спрос на альтернативных вендоров поддержки, отчасти потому что MongoDB как компания много работала над позиционированием себя как альтернативы MySQL.

Мы смогли приобрести компанию TokuTek, которая уже предоставляла услуги поддержки MongoDB и своего “форка” MongoDB, известного на рынке. Это позволило нам успешно выйти на новый рынок, не делать все с нуля. Не случись этого, нам потребовалось бы больше времени, чтобы начать заниматься чем-то кроме MySQL.

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

Петр: У нас сейчас работает около 150 человек, 30 разных стран, 20 разных штатов США. В основном, люди работают из дома. В США, в Северной Каролине, у нас есть небольшой офис, там в среднем работает 5 человек в день. Он сделан так, чтобы там было удобно проводить встречи. К нам часто приезжают гости. Также у нас есть много маленьких офисов.

На мой взгляд, не совсем правильно ставить в один ряд бизнес в области поддержки и консалтинговый бизнес. Мы начинали как консалтинговая компания, и через несколько лет нам стало сложно развиваться. Компания росла, усложнялась её структура, увеличивались издержки, мы стали заниматься разработкой программного обеспечения — такого как Percona Server для MySQL. Консалтинг часто является достаточно непредсказуемым: бывают периоды, когда клиенты приходят один за другим, но иногда случается менее “урожайный” сезон, и тогда тебя куча консультантов, которым нечем заняться.

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

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

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

PG Day: Ты начал говорить про клиентов корпоративного уровня. Я думаю, не секрет, что у вас много очень крупных клиентов типа BBC, Airbnb, Cisco и так далее. Каковы основные сложности взаимодействия с клиентом такого уровня?

Петр: У крупных компаний более высокие требования к структуре и постоянству результата. Это было для меня одним из челленджей в трансформации “Перконы”. Когда мы начинали, мы работали со многими стартапами. Интересные, активные ребята, которые могли сказать «Слушайте, как классно: я “Перконе” задаю вопрос и получаю от них три разных мнения, которые имеют право на существование». Мы все понимаем, что в области технологий нет единственно правильного решения, как в задаче по математике. Обычно их несколько, и все вполне приемлемые: можно сделать так или эдак, и всё будет работать. Поначалу мы нанимали таких умных, независимых ребят и говорили: «Ребята, делайте, как хотите. Главное, чтобы это было разумно, и клиент был доволен».

Когда мы начали работать с enterprise-клиентами, ожидания стали меняться. Они хотят постоянства — как, например, в Starbucks, которые говорят: «Ребята, нам не нужен самый лучший кофе в мире, но мы хотим приходить, просить капучино, и пусть он всегда будет абсолютно одинаковый». Корпорации уделяют этому аспекту очень много внимания. Они хотят задавать один и тот же вопрос (что они часто делают, потому что у них много команд, которые сталкиваются с одними и теми же проблемами) и рассчитывать на получение одного и того же ответа. Если они получают каждый раз разный ответ, их это просто сводит с ума. И это требует совершенно другого подхода к организации команды. Это требует создания внутренних процессов, внутренних баз знаний и так далее, чтобы мы гарантировали, что если у нас спрашивают вот такую вещь, то ответ от “Перконы” всегда будет такой. Можно придумать еще 25 разных ответов, которые тоже будут правильными, но наш ответ такой. Для меня это было не очень понятно, потому что несколько ограничивает креативность. Но многие enterprise-клиенты требуют и ожидают именно этого.

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

Петр: Да, я согласен, удалённый найм — вопрос сложный. Но у этой модели есть свои преимущества: если ты ищешь людей всему миру, то у тебя большой пул потенциальных кандидатов, не нужно ограничиваться рамками твоего города. В маленьких городках специалистов не хватает. Если ты находишься в Нью-Йорке или Сан-Франциско, специалисты есть, но за ними ведут охоту богатые компании. Есть еще аспекты, связанные с культурой. Представители некоторых культур на собеседовании будут отвечать, что они знают все. Другие люди более критичны к себе — в частности, русские. Очень часто слышишь: «Ну, я SQL не особенно хорошо знаю. Английский у меня плохой». Начинаешь говорить с человеком, а он и по-английски хорошо говорит, и MySQL совсем неплохо знает, просто у него очень высокие требования к себе.

Что еще интересно? Поскольку интервью проходит удаленно, мы проводим несколько собеседований с привлечением разных людей. Это у нас занимает больше времени, чем обычно, поскольку мы не приглашаем человека в офис. Понять с помощью устных вопросов, насколько человек хорош, сложно. Поэтому для многих позиций мы проводим тесты. У нас есть специальный тренажер: сломанная система, в которую нужно залогиниться и починить её. При этом один из наших сотрудников играет роль клиента, с которым можно общаться. Это позволяет проверить очевидные вещи, например, спросит ли кандидат: «А можно ваш сервер перезапустить?» Некоторые специалисты не понимают, что, работая с клиентами, эти моменты нужно уточнять. Им дали сервер “пофиксить”, и они считают, что теперь они могут все, что угодно: “положить” его на час, операционку переустановить. Мы смотрим не только на технические знания, но и на умение вежливо общаться, оценивать каковы потребности клиента, о чём его нужно информировать. Хороший сервис тоже важен.

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

Расскажу об одном моем трюке. Я понимаю особенность технических позиций: у знаний очень небольшой период полураспада, образно выражаясь. Если сравнить то, что необходимо знать сейчас, и то, что требовалось знать 5 лет назад, выяснится, что появилось много нового, а половина старого багажа знаний уже не актуальна. Необходимо, чтобы человек мог быстро и эффективно учиться, поглощать новую информацию. В разговоре с кандидатами я нахожу что-то, о чём я имею большее представление, чем они. И, когда они начинают “плавать”, я говорю: «Отлично, ты же у компьютера сейчас. Давай я тебе дам пять минут, погугли, проведи исследование темы, а потом мы об этом поговорим снова!» Для меня это очень хороший показатель того, насколько толковым является человек. Специалисты, которые умеют быстро находить и усваивать информацию, обычно хорошо справляются со всеми обязанностями. У кого-то, возможно, и есть нужные нам сейчас знания, но информацию он усваивает очень медленно и плохо. Такой человек вряд ли сможет у нас работать.

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

Петр: Риск, безусловно, есть. И кажется, если сотрудник находится где-то в другом месте, всё гораздо более страшно. Хотя, на самом деле, можно работать с человеком близко, а потом он учудит то, чего ты не ожидал. Поэтому я не считаю, что в данном случае риски существенно выше. Со своей стороны мы стараемся делать проверку рекомендаций, делаем background check человека: нет ли у него какого-то криминального прошлого, не наврал ли он, что учился в университете таком-то. Мы много людей нанимаем по личным рекомендациям. Могу сказать, что за 10 лет работы были разные случаи. С кем-то нам повезло, с кем-то не очень. Ошибки, конечно, люди допускали, но чтобы кто-то навредил из злого умысла — такого не было.

PG Day: В заключение, дай, пожалуйста, небольшой анонс мастер-класса, который ты будешь читать на PG Day’17.

Петр: Это хороший обучающий мастер-класс, в рамках которого мы поговорим об оптимизации и архитектуре InnoDB. Это подсистема хранения, storage engine, которая используется, наверное, в 99% инстансов MySQL по всему миру. Я читаю этот курс за границей на наших конференциях Percona Live более пяти лет, и всегда успешно. Каждый год я обновляю материал: появляются новые версии MySQL, какие-то новые возможности. Обычно с посещаемостью всё отлично, и я получаю хороший фидбек от людей. Им не надоедает. Мастер-класс выстроен как лекция, на очень детальном уровне рассматривающая наиболее важные аспекты InnoDB: как работает эта подсистема хранения, как устроены данные на физическом уровне, как работают транзакции, что происходит при разных операциях чтения, записи и так далее. Я считаю, что после прохождения обучения слушатели получат ясное представление о том, что для InnoDB хорошо, что плохо, почему база “тормозит” в каких-то ситуациях и что нужно делать, чтобы этого избежать.

PG Day: Кому в первую очередь может быть интересно участие в мастер-классе?

Петр: Больше всего этот мастер-класс интересен DBA и системным администраторам, которые работают с MySQL. Им нужно знать, как задействовать максимум возможностей MySQL. У слушателей будет много шансов задать вопросы, обсудить какие-то свои прикладные проблемы в разрезе изучаемого материала.

PG Day: Спасибо, Петр!

https://habrahabr.ru/post/330716/

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

Что вы получите «из коробки»:

• Обнаружение датчиков температуры, напряжения, оборотов
• Триггеры, основанные на показаниях SDR

Суммарно понадобятся:

1. Скрипт на Bash
2. Шаблон
3. Документация или Интернет для переименования элементов

Для начала уточню, что у вас должен быть подготовленный рабочий сервер Zabbix 3.2, настроенный узел IPMI.

Скрипт

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

Шаблон

Для каждого подключаемого узла необходимо указать 4 макроса, а именно: {$IPMIIP}, {$IPMIPRIV}, {$IPMIUSER}, {$IPMIPASS}. Значения их интуитивно понятны, кроме только что {$IPMIPRIV} — это роль пользователя (ADMIN, USER и т.д.). Вносить их нужно, так как в Заббиксе нет стандартных макросов на этот счет. Возможно, в будущем они появятся.

Особенность шаблона, как и в прошлой статье, состоит в двойном преобразовании макросов {${#X}}. Оно позволяет заменять имена сенсоров на читаемые. Согласитесь, приятнее выглядит «Напряжение батареи BIOS», а не «Напряжение BB_3.3V_VBAT».
Все что вам нужно сделать для этого — внести соответствующий макрос в список шаблона в виде:
{$CPU1_TEMPERATURE} = CPU1
В списке уже есть несколько преобразований для Intel S1200 и Asus RS300.

Немного о фильтрации

Не все датчики нужно считывать, это факт. К примеру, зачем мне суммарный запас (Agg Margin) по температуре? Для таких случаев для каждого обнаружения есть свой фильтр. Но увы, переключить его в режим «не совпадает» нельзя. Возможное решение — использовать глобальные регулярные выражения (Результат ЛОЖЬ). В фильтр же добавляется имя выражения с символом @.
Для каждого из обнаружений для себя я сделал: IPMI-FAN, IPMI-VOLT, IPMI-TEMP (в шаблон они не попадают).

Немного о триггерах

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

Итого

Свои zabbix-велосипедырешения и периодически дорабатываю. В этой статье представлен стартовый шаблон. И разрабатывался он с небольшим запасом под масштабируемость. К примеру, заменив последнюю переменную в ключе ipmi.sh[..] можно снимать мощность, воздушный поток, другие показатели. Применение ограничено вашей изобретательностью.

https://habrahabr.ru/post/330604/

Что такое полное погружение? Это когда разница между виртуальным и реальным мирами не ощущается. То есть, ты не чувствуешь, в каком из миров находишься.
В статье мы поговорим о том, что представляют собой технологии для полного погружения в виртуальную реальность в настоящее время, про плюсы и минусы разных типов обратной тактильной связи и про будущее полного погружения.
Материал подготовлен на базе лекции Дениса Дыбского, которая проходила на конференции VR-Today в рамках нашей образовательной программы «Менеджмент игровых проектов» в ВШБИ. Видео и конспект под катом.

Составляющие полного погружения

• Первый и самый важный момент — это визуальная картинка. Все привыкли, что погружение в виртуальную реальность происходит с помощью шлемов виртуальной реальности. Как правило, HTC Vive, Oculus Rift, Gear VR, PS VR и прочих шлемов, которые сейчас есть на рынке.
• Второй важный момент — это звук. Без звука в виртуальную реальность невозможно погрузиться на данный момент, поскольку картинка должна полностью сочетаться со звуком. Для того, чтобы пользователь, находясь в виртуальной реальности, смог позиционировать себя в пространстве и знать, где он находится.
• Следующий, еще более важный момент — это тактильная связь или haptic. В западной терминологии он называется haptic feedback — “обратная тактильная связь”.
• Симуляция вкуса.
• Симуляция запаха.
• Положение человека в пространстве.

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



Типы обратной тактильной связи:

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

Существующие проблемы

1. Сейчас для погружения в виртуальную реальность стимулируется всего лишь 2 чувства из 5 — это зрение и слух.
2. Еще бОльшая проблема, чем предыдущая — это наличие проводов в PC и консольных шлемах. Через шлем виртуальной реальности проходит большой объем данных, а для этого нужны провода. Для того, чтобы почувствовать себя полностью свободным в виртуальной реальности, нужно их убрать.
3. Проблема взаимодействия с виртуальным миром. Как правило, для того, чтобы полноценно с ним взаимодействовать, нужны контроллеры. Сейчас в роли контроллеров у разных производителей выступают обычные контроллеры Vive, Oculus Touch и др. Но для того, чтобы полноценно взаимодействовать с объектами, иметь возможность дотронуться до них, повернуть, взять, почувствовать его текстуру, вес, нужны перчатки виртуальной реальности. Что в них должно входить: как минимум это система захвата движения для того, чтобы можно было отслеживать положение руки в пространстве, то, как двигаются пальцы, сжимаются ли они, как рука поворачивается относительно всего тела. Должна отслеживаться мелкая моторика. При прикосновении к виртуальному объекту должна быть обратная связь. К примеру, текстуру можно сделать с помощью электростимуляции. Если это какой-то большой объект, к примеру, человек натыкается на стену руками, то, естественно это можно сымитировать вибротактильным фидбеком.
4. Из-за того, что на данном моменте на рынке присутствуют решения, которые в основном используют вибрацию либо силовой фидбек, это уменьшает качество взаимодействия в виртуальной среде, потому что они не позволяют максимально точно передать все ощущения.
5. Еще один момент: в виртуальной реальности при полном погружении нужно имитировать ходьбу. Как это можно сделать? Первый способ — это телепортация. К примеру, это реализовано в HTC Vive, там с помощью контроллера можно телепортироваться в разные места в виртуальной среде. Второй — это непосредственно физическая ходьба по помещению. Но для того, чтобы полностью погрузиться, в зависимости от объема виртуального мира, в который вы погружаетесь, нужно маленькое либо большое помещение. Но для полноценного перемещения в максимально больших открытых мирах невозможно использовать только небольшое помещение. Поскольку нужно ходить во все стороны, это не очень удобно. Третий более-менее решающий эту проблему гаджет, это Tread Meal (сейчас есть несколько предложений на рынке), который позволяет прямо в нем двигаться, он поддерживает тело человека и не дает человеку уставать.

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

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

CAVE
Это проект, который был запущен в 1992 году. Он состоит как правило из огромных дисплеев по всей комнате. Это встроенные в стену колонки, направленный звук, система захвата движений и стереоскопические дисплеи.

The VOID
Парк развлечений VR, открывшийся несколько лет назад в Юте, США. Физические локации, по которым в нем можно ходить, полностью соответствуют виртуальным.

AlloSphere
10-метровая сфера со множеством стереоскопических дисплеев, встроенной системой захвата движения, звуком и так далее.

Teslasuit
Костюм для полного погружения в VR. Выглядит как обычный костюм, имеет в себе несколько систем.

• Система передачи ощущений, то есть, система обратной тактильной связи Haptic Feedback System. Она позволяет маскимально точно передавать ощущения VR. Можно почувствовать, как к тебе кто-то прикасается, даже если он находится за 1000 км от тебя.
• Система захвата движений. Позволяет пользователю отслеживать его положение в пространстве и перемещения по нему. На данный момент это инерционный трекинг, но сейчас разрабатывается гибридный мокап, в котором будет использоваться и оптический трекинг.
• Климат контроль. Позволяет чувствовать холод, тепло, снижение или увеличение температуры.
• Костюм полностью беспроводной.
• Для того, чтобы позволить сторонним разработчикам использовать костюм, был разработан собственный SDK.
• Перчатка с хаптиком.
• 5G и облако для процессинга (в планах). Сегодня все девайсы требуют мощного железа для того, чтобы полноценно запускать контент и не было никаких лагов. Костюм позволит весь процессинг перевести в облако. Это избавит пользователей от железа, уберет всю лишнюю периферию. Поскольку периферия очень сильно снижает мобильность в VR, облако должно быть довольно мощным, распределенным и еще много всяких нюансов. Поэтому его создание займет не менее 3-5 лет.

А теперь немного заглянем в будущее

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

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

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

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



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

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

https://habrahabr.ru/post/330754/

Привет, хабр!

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

1. if (!ReferenceEquals(arg, null)) throw…
2. Code Contracts: Contract.Requires(!ReferenceEquals(arg, null))
3. Guard.IsNotNull(arg, nameof(arg))

В статье я рассмотрю только третий вариант (все примеры кода — для C#, однако некоторые из них будут полезны и в Java).

Ошибка №1: не подготовились к проверкам аргументов и в теле метода

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

Итак, для начала лучше всего заранее договориться об именованиях обоих случаев. Например, Guard.IsNotNull для тела метода и Guard.ArgumentIsNotNull для аргументов

Ошибка №2: вызов string.format при каждой проверке

Сразу примеры ошибочного кода:

Guard.IsNotNull(connection, $"Unable to setup connection with host {host} and port {port}")
Guard.IsNotNull(connection, string.Format("Unable to setup connection with host {0} and port {1}", host, port)) // это просто развернутая строчка выше

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

public static class Guard
{
    public static void IsNotNull(object value, string format, params object[] formattingArgs) // тут мы сконструируем строку в самый последний момент, когда выделение небольшого куска памяти уже не будет ударять по производительности
}

На самом деле вариант выше тоже плохой. В нем уже не создается строка, однако на каждый вызов метода создается новый массив formattingArgs. Конечно, для него выделяется меньше памяти, однако такие методы всё равно будут нагружать на сборщик мусора.
Самое обидное, что программа будет тормозить, однако простой профайлинг не подстветит проблему. У вас просто программа будет чаще останавливаться для очистки памяти (я исправил такую ошибку в одной из программ, сборка мусора стала занимать вместо прежних 15% всего лишь 5%).

Итак, поступаем так же, как сделано в string.Format: нагенерим побольше методов для разного числа аргументов.

public static class Guard
{
    public static void IsNotNull(object value, string errorMessage)

    public static void IsNotNull(object value, string errorMessageFormat, object arg1)

    public static void IsNotNull(object value, string errorMessageFormat, object arg1, object arg2)

    public static void IsNotNull(object value, string errorMessageFormat, object arg1, object arg2, object arg3)
}

Итак, теперь массив выделяться не будет. Однако, мы автоматом получили новую проблему — Boxing.
Рассмотрим вызов метода: Guard.IsNotNull(connection, "Unable to setup connection with host {0} and port {1}", host, port). Переменная port имеет тип int (чаще всего по крайней мере). Получается, что для того, чтобы передать переменную по значению, .Net каждый раз будет создавать int в куче, чтобы передать его как object. Эта ситуация будет встречаться намного реже, но всё же будет.
И другая проблема — если изначальный проверяемый объект — это value type (например, мы проверяем на null в generic методе, который не имеет ограничений на тип).
Исправить это можно увеличением созданием Generic методов для проверок:

public static class Guard
{
    public static void IsNotNull(TObject value, string errorMessage)

    public static void IsNotNull(TObject value, string errorMessageFormat, TArg1 arg1)

    public static void IsNotNull(TObject value, string errorMessageFormat, TArg1 arg1, TArg2 arg2)

    public static void IsNotNull(TObject value, string errorMessageFormat, TArg1 arg1, TArg2 arg2, TArg3 arg3)
}

Ошибка №3: отсутствие кодогенерации

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

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

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

Еще улучшения

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

ReSharper Annotations

Часто ReSharper ругается, что значение может быть null, хотя его вроде бы проверили с помощью Guard'а. В этом случае можно либо начать постепенно забивать на предупреждения в коде (что может быть чревато), либо объяснить проверяющим, что всё нормально. Полный список аттрибутов можно просмотреть здесь, однако вот полезные для нас:

• AssertionMethodAttribute и AssertionConditionAttribute — они вдвоем объяснят системе, что метод только проверяет аргумент, а заодно и распишут, что именно проверяют
• NoEnumerationAttribute — покажет, что если передать на вход IEnumerable, то по нему никто не будет итерироваться
• CollectionAccessAttribute — если вы вдруг решили проверить все аргументы коллекции (например, что их не больше пяти, и что они не null), то с помощью этого аттрибута можно сказать, что именно происходит с коллекцией (чтение, запись и т.д.)
• StringFormatMethodAttribute — объясняет, что один из параметров является строкой, которую потом будут использовать как формат. В этом случае её дополнительно проверят, что она может быть разобрана string.Format, что число аргументов соответствует ожиданиям и т.д. Я, кстати, еще не видел проекта, в котором была бы отключена эта проверка, и в котором после её включения не было бы ошибок, что string.Format просто не может выполниться

Записывать больше информации

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

1. Тип (а лучше — вызов ToString у него), который оказался некорректным.
2. Если есть еще аргументы для сравнения — то информацию о них тоже
3. Полный stacktrace (т.к. иначе он обрезается до места, где исключение было поймано)

Заключение

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

https://habrahabr.ru/post/330150/

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

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

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

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

Космос

Дорогой дефис

Спутник Mariner 1 в 1962 году должен был отправиться к Венере. Стартовав с мыса Канаверал, ракета практически сразу сильно отклонилась от курса, что создало серьезную угрозу падения на землю. Для предотвращения возможной катастрофы NASA было принято решение запустить систему самоуничтожения ракеты. Спустя 293 секунды с момента старта, Mariner 1 был ликвидирован.

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

Программист неправильно перевел написанную формулу в компьютерный код, пропустив макрон или надчёркивание (что значит "n-ое сглаживание значения производной радиуса R по времени").

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

Цена "пропущенного дефиса" — 18 млн долларов (на тот момент).

Российский GPS, опустившийся на дно

Ярким примером того, как из-за программной ошибки могут быть потеряны миллионы, является относительно недавний случай. Казалось бы, в 21 веке есть все необходимое для написания надёжных программ, особенно, если речь идет о космической отрасли. Опытные специалисты с отличным образованием, хорошее финансирование, возможность использования лучших инструментов для проверки программного обеспечения. Все это не помогло. 5 декабря 2010 года ракета-носитель "Протон-М" с тремя спутниками "Глонасс-М" — российский аналог GPS, упала в Тихий океан.

Причину аварии, после завершения расследования, озвучил официальный представитель Генпрокуратуры РФ Александр Куренной: "Установлено, что причиной аварии стало применение неверной формулы, в результате чего масса заправленного в бак окислителя разгонного блока жидкого кислорода на 1582 кг превысила максимально допустимую величину, что повлекло выведение ракеты-носителя на незамкнутую орбиту и его падение в акваторию Тихого океана" (источник).

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

Автомобили

Еще в 2009 году профессор информатики в Техническом университете Мюнхена, эксперт по программному обеспечению в автомобилях Манфред Бра, сказал: "Программное обеспечение автомобиля премиум-класса содержит около 100 миллионов строк кода" (источник). С того момента прошло уже восемь лет, и совсем не обязательно быть поклонником передачи Top Gear, чтобы заметить: современные автомобили — это настоящие интеллектуальные машины.

По заявлению все того же эксперта, стоимость программного обеспечения и электроники в автомобиле составляет порядка 40% от его цены на рынке. И это касается бензиновых моторов, что же говорить о гибридах и электрокарах, где это значение равно примерно 70%!

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

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

И снова Toyota

Японские автомобили Toyota имеют положительную репутацию, но периодически в СМИ попадает информация об отзыве некоторого количества машин. В нашем блоге уже есть статья о программной ошибке в Toyota — "Toyota: 81 514 нарушений в коде", но этот случай, к сожалению, не единичный.

В 2005 году было отозвано 160 тыс. гибридов Toyota Prius 2004 года выпуска и начала 2005. Проблема заключалась в том, что машина могла в любой момент остановиться и заглохнуть. На устранение бага было затрачено около 90 минут на одно транспортное средство или около 240 тыс. человеко-часов.

Chrysler и Volkswagen

В мае 2008 года Chrysler отозвал 24535 автомобилей Jeep Commanders 2006 года выпуска. Причина — программная ошибка в модуле управления автоматической трансмиссией. Сбой приводил к неконтролируемой остановке двигателя.

В июне того же года Volkswagen отзывает около 4000 Passat и 2500 Tiguans. Здесь ошибка в программном обеспечении оказывала воздействие на увеличение оборотов двигателя. Показания тахометра начинали ползти вверх при включенном кондиционере.

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

Tesla

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

Поговорим, конечно же, о Tesla Model S. 7 мая 2016 Джошуа Браун, прославившийся благодаря своим роликам на YouTube, посвященным восхвалениям электромобиля, попал в автокатастрофу. Он находился за рулем Tesla Model S. Будучи на 100% уверенным в интеллекте машины, он доверился автопилоту. Результат доверия трагичный — от полученных травм Джошуа скончался на месте.

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

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

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

Представители компании привели следующую дорожную статистику: "На каждые 90 млн. миль пройденного пути умирает один человек. В противоположность, люди проезжали 130 млн. миль на автопилоте Тесла перед тем, как была подтверждена первая смерть. Сейчас эта цифра поднялась до 200 млн." (источник)

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

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

Всеобщий масштаб — Беда 2038 года

Не могла не привести в завершении статьи этот пример. Подробно о Беде 2038 года вы можете прочитать в статье "2038: остался всего 21 год", я же остановлю внимание на одном важном моменте.

Оборудование для заводов: всевозможные станки, конвейеры; бытовая техника и другие сложные агрегаты, оснащенные специализированным программным обеспечением, имеют достаточно продолжительный срок службы. Вероятность того, что выпущенный в 2017 году станок будет функционировать и в 2038 очень и очень велика. Отсюда логично сделать вывод: проблема, когда 32-битные значения типа time_t больше не смогут корректно отображать даты, уже актуальна!

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

Заключение

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

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

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

Желаю вам не допускать промахов, а вашим проектам никогда не попасть в подборку, аналогичную той, что приведена в этой статье.

https://habrahabr.ru/post/330762/

Последние года два мой отдел плотно занимается проектами миграции корпоративных почт с зарубежных сервисов в MS Exchange базе инфраструктуры наших дата-центров. Из облачных сервисов типа Office 365, Gmail в основном мигрируют из-за ФЗ-242, так как хотят, чтобы почта жила на российской инфраструктуре. Это не единственная причина: часть компаний после миграции целиком передает нам почтовую систему на администрирование под жесткий SLA, что не всегда можно получить в массовых сервисах. Те, у кого почта раньше жила на железе и кто хочет расширяться, не связываясь с покупкой нового оборудования, также обращаются к нам, скромному российскому облачному провайдеру.

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

Что хотите получить на выходе

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

• функциональность, которую ожидаете получить от новой почтовой системы: объем трафика, календари, UM, общие папки и пр.
• доступность на этапе миграции и после. Готовы ли вы на простои? Если да, то в каком объеме и когда? На какую доступность рассчитываете после миграции, когда ваши пользователи будут работать с новой системой?
• какие бизнес-процессы завязаны на почтовую организацию: работа службы поддержки, маркетинговые рассылки и пр.
• с какими решениями нужно интегрировать (1C, Sharepoint, Skype и пр.). Был случай, когда ИТ-менеджер стартовал миграцию почты из Lotus в Exchange, и на полдороге выяснилось, что у них есть еще и корпоративный портал, завязанный на Lotus. Переезжать на новый портал они не планировали, поэтому свернули миграцию, а непредусмотрительного менеджера уволили.
• примерные сроки миграции. Даже если все правильно посчитать с учетом объемов данных, которые нужно перенести на новую площадку, обязательно всплывут непредвиденные технические ограничения: канал связи окажется медленнее, чем ожидалось, или обнаружатся лимиты на экспорт данных из исходной почтовой системы.

С последним мы столкнулись, когда перевозили клиента из Gmail. В процессе выяснилось, что за сутки можно экспортировать не более 1,5 ГБ данных. Даже если ящик был всего на 2 ГБ, то его приходилось экспортировать два дня – 1,5 ГБ, потом сутки ждем и докачиваем оставшиеся 500 ГБ. Перенос ящиков на 20 ГБ занимал почти два недели.
Пока все экспортировалось небольшими порциями, жизнь в компании не останавливалась и приходила новая почта, которую тоже нужно синхронизировать с новой площадкой. Проблему удалось решить с помощью утилиты Cloudiway: она вытягивала все содержимое ящиков с учетом суточного лимита, т.е. нам не приходилось вручную раз в сутки выкачивать разрешенные 1,5 ГБ. Затем вытягивала дельту писем, которые падали за то время, пока она тянула основной объем. Со временем дельта все уменьшалась и уменьшалась, и после того как все данные из исходного ящика были перенесены, мы переключали пользователя на работу с целевой почтовой системой.

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

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

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

Аудит существующей инфраструктуры

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

• входящий и исходящий объем SMTP-трафика;
• количество и суммарный объем почтовых ящиков;
• количество конечных пользователей;
• расположение клиентов: они могут подключаться изнутри сети и снаружи сети, с доменных или недоменных машин;
• протоколы клиентских подключений и версии клиентов (MacOS-клиент, Outlook Anywhere, POP3, IMAP, ActiveSync);
• текущая конфигурация почтовой системы:
  — количество SMTP-доменов организации;
  — количество групп рассылок;
  — наличие ящиков большого размера (от 20 ГБ);
  — наличие сервисных ящиков (для 1С, сканеров, рассылок);
  — массовые рассылки.

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

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

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

Выбор архитектуры MS Exchange будет зависеть от требований к доступности. Вариантов два:

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

High Availability. Все роли почтовой системы дублируются. Серверы MailBox (на схеме – MBX) добавляются в группу высокой доступности (Database Availability Group, DAG). При отказе одного из серверов почтовые базы переедут на резервные. Конечный пользователь ничего не заметит. Эту схему можно реализовать и в рамках двух дата-центров. Тогда почтовой системе не будет страшен выход из строя целого ЦОДа.
Эта архитектура – для тех компаний, для которых неприемлем простой. Чаще всего это большие компании.

Схема HA.

Выбор антиспам/антивирус-решения

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

Сайзинг почтовой системы

Вопрос не стоит, если новая система – полный клон старой и мы ничего не планируем в ней менять. Для остальных случаев придется посчитать ресурсы. У MS есть инструмент (на самом деле просто excel-табличка с кучей параметров:)), с помощью которого можно просчитать объем ресурсов для инсталляции Exchange – Microsoft Exchange Sizing Calculator. Сразу скажу, что инструмент не интуитивный и потребует времени, чтобы разобраться, но это неплохой вариант, если за плечами нет опыта сайзинга подобных проектов.
При расчете не забываем делать поправку на то, что почтовая система будет бэкапиться, а значит скорость бэкапа будет в том числе зависеть от типа используемых дисков. Если планируете использовать антивирус, который будет проверять базу онлайн, то логичнее выбрать SAS-диски, но, конечно, выбор типа дисков должен базироваться на анализе реальной нагрузки на систему.
Так как миграция происходит не одномоментно, особенно для больших компаний, нужно предусмотреть возможность масштабирования инфраструктуры под почту (в одном проекте за время миграции численность пользователей успела вырасти в 2 раза – было 1000, стало 2000). Если под систему используются виртуальные ресурсы, то это сделать проще.

Способ миграции

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

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

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

План миграции, инструкции, регламенты

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

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

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

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

В одном из проектов миграции из Office 365 в Exchange была следующая ситуация. На исходной системе у пользователей была две учетки – для входа на компьютер (AD-учетка) и для входа в почту, в Office 365. После миграции должна была остаться одна учетная запись. Пользователей было около 600, поэтому важно было до них четко донести, какую из учетных записей использовать в новой системе.

На этом все. Задавайте вопросы в комментариях. И всем удачных переездов.

https://habrahabr.ru/post/330756/

Каждый год WebCanape организует большой фестиваль Tabtabus для айтишников и предпринимателей. В 2016 году мы поставили себе цель собрать с ночевкой в палатках 400+ человек на берегу красивого озера. Нижеописанный лайф-хак очень помог нам в этом.

В чем суть идеи?

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

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

Автоматизируем сервис для народа

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

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

Попробуйте воспользоваться сервисом аватарок >>

• Пример сгенерированного пользователем профиля: avatar.web-canape.ru/client?id=5
• Пример накладки в PSD yadi.sk/d/HoGOG2u-3HDBd7

Несколько рекомендаций на основе нашего опыта

• Рекомендуем давать пользователю выбор из вариантов шаблонов аватарки. Пусть он будет вовлечен в этот процесс. Чем больше времени он потратит на генерацию своей аватарки, тем больше шансов, что он ее разместит :)
• Не стоит перегружать аватарку графикой. В этом случае люди просто не будут ее размещать. С вашим шаблоном аватарка должна стать стильней, а не наоборот. Человек должен быть на первом плане, графика — дополнять и украшать.
• Попросите дизайнера сделать накладку. Это займет час его времени.
• Убедите спикеров поставить аватарку. Как это сделать? Просто попросите их об этом. Им же тоже важно привлечь на свое выступление заинтересованную публику. Хорошее мероприятие — это совместный труд выступающих и организаторов.

Если это поможет вам собрать аудиторию, просто расскажите нам об этом. Уже будет приятно. Всем полных залов и хороших ивентов! Да, и не забудьте заглянуть к нам на Табтабус :)

https://habrahabr.ru/post/330658/

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

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

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

/ изображение Susana Fernandez CC

Сегодня к блокчейну активно присматриваются банки, энергетические компании, участники рынка интернета вещей и государственные организации. Например, Bank of America и Microsoft начали совместную разработку финансовой блокчейн-платформы, а компания Chronicled запустила блокчейн-платформу для интернета вещей, которая создает безопасные и совместимые со множеством других систем цифровые идентификаторы. Однако окружение и условия, в которых работает биткойн, значительно отличаются от тех, какими они были в момент зарождения криптовалюты. Количество пользователей выросло до нескольких десятков миллионов человек (более 13 млн), что вызвало увеличение числа ежедневных транзакций (порядка 400 тыс.).

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



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

Однако такая мера безопасности оказала негативный эффект на пропускную способность сети в целом (в долгосрочной перспективе). На сегодняшний день биткойн может обработать порядка 7 транзакций в секунду (TPS). При этом фактическая нагрузки на сеть биткойна составляет 3,5 TPS. Для сравнения, показатель TPS в системе Visa равен 2 000 (в моменты пиковой активности — 50 000).

Ранние предложения по решению проблемы

Первые предложения по улучшению биткойна были представлены в 2015 году (BIP 100 и BIP 101) разработчиками ядра Джеффом Гарзиком (Jeff Garzik) и Гевином Андресеном (Gavin Andresen). Оба решения предлагали увеличить размер блока, однако являлись хардфорками, то есть не имели обратной совместимости. Это означало, что при их реализации старое программное обеспечение становилось несовместимым с новой сетью. В BIP 100 предлагалось настраивать размер блока по решению майнеров, а в BIP 101 — единовременно увеличить размер блока до 8 мегабайт.

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

Segregated Witness

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

20 мая ключевые игроки биткоин-индустрии все же смогли найти точки соприкосновения. Участники конференции Hong Kong Bitcoin Roundtable Consensus (в том числе компания BitFury) согласились поддержать несколько апгрейдов протокола биткойна. Один из них —это активация Segregated Witness по достижении уровня поддержки в 80% (мощности майнеров). Второй связан с увеличением размеров блока до 2 МБ. Это решение даже повлияло на стоимость биткойна. Интерес к криптовалюте и новые открывающиеся возможности по масштабированию блокчейна привели к тому, что цена за биткойн перевалила отметку в 2,5 тыс. долларов.



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

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

Технология Segregated Witness видоизменяет эту цепочку взаимодействий. Вновь созданные выводы начинают использовать другой тип запирающего скрипта, который получил название «тратит кто угодно» (anyone can spend), поскольку не требует цифровых подписей, и на первый взгляд может быть потрачен кем угодно. Хитрость в том, что запирающий скрипт вида anyone can spend содержит специфическую последовательность байтов, которая привязывает к скрипту «настоящие» условия траты биткойнов.

Похожий прием используется в P2SH (Pay to Script Hash). Как и в случае SegWit, с P2SH биткойны по-прежнему запираются в сценарии, однако в выход транзакции добавляется не сам запирающий сценарий, а его хеш. Для того, чтобы потратить биткойны, запертые таким сценарием, нужно знать не только «настоящий» запирающий сценарий (как может показаться при первом прочтении scriptPubKey), но и отпирающий scriptSig для этого сценария (например, цифровую подпись).

Segregated Witness, по сути, выделяет scriptSig (подписи транзакций) в отдельную структуру данных — witness (доказательство). Таким образом, SegWit является аддоном, который полностью игнорируется старыми узлами, но признается новыми. И старые и новые узлы считают транзакции с SegWit корректными: первые видят скрипты «тратит кто угодно» и считают транзакцию корректной (хотя и странной с точки зрения семантики), а вторые — обращаются к подписи в witness. За счет этого технология позволяет устранить плавкость транзакций (tx malleability), сохранить дисковое пространство и оптимизировать скорость проверки подписей.

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

Еще одним достоинством SegWit может служить тот факт, что в нем сохраняются байты версий. Они предшествуют скрипту и обозначают его тип. Это дает возможность обозначать требования, необходимые для высвобождения биткойнов. Фактически это позволит запирать биткойны самыми разными способами. Реализовать потенциал этой функции смогут подписи Шнорра, которые более компактны и верифицируются быстрее нынешних ECDSA-подписей, а также более сложные типы мультисигнатурных транзакций и даже смарт-контракты, подобные Ethereum.

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

"scriptPubKey": {
"asm": "0 07389b37ea077e9431a2e64530649f8a61befa54",
"hex": "001407389b37ea077e9431a2e64530649f8a61befa54",
"type": "witness_v0_keyhash"
}

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

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

Как именно стоит проверять SegWit-сценарий, узел определяет на основе байта версии и длины следующего элемента scriptPubKey (в примере выше — 20). Пока в SegWit определены 2 типа сценариев: на основе публичного ключа (наш пример) и более сложный для произвольных проверок (например, мультисигнатур). Во втором случае в scriptPubKey записывается 32-байтовый хеш «настоящего» запирающего сценария. Во время траты средств, этот сценарий, вместе с подходящим отпирающим сценарием, должен быть предоставлен в поле witness. При этом хеш запирающего сценария должен совпадать со значением, указанным в scriptPubKey.

Lightning Network

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

Главная особенность Lightning Network — это двунаправленные «бездоверительные» платежные каналы, которые позволяют обмениваться биткойнами напрямую, минуя блокчейн. В блокчейн транслируются только открывающие и закрывающие канал транзакции, даже если между ними были совершены миллионы платежей. Это позволяет серьезно «разгрузить» блокчейн и повысить его пропускную способность, а также проводить микроскопические платежи (например, посекундно оплачивать цифровой контент или интернет-связь). Более того, LN позволяет проводить платежи через одного или более промежуточных узлов сети без риска, что эти узлы смогут похитить средства. За счет этого обеспечивается масштабируемость LN до миллионов узлов. Подробнее о принципах работы LN мы планируем рассказать в последующих материалах.

P.S. Наши вакансии на HH и англоязычный блог на Medium.

P.P.S. Дополнительные материалы по теме:

• Валерий Вавилов, BitFury Group: «Блокчейн — индустрия на триллионы долларов»
• Иное применение блокчейнов: Смарт-контракты
• Что такое эксклюзивные блокчейны

https://habrahabr.ru/post/330726/

1. Введение

Forge Reply — это миланская игровая студия. Нашим наиболее важным проектом на сей день является гибрид игры-книги/JRPG Joe Dever's Lone Wolf. Игра в четырёх актах была выпущена на мобильных устройствах в 2013-2014 годах. Потом её портировали на другие платформы (PC, PlayStation 4 и Xbox One).

Joe Dever's Lone Wolf создана на заре высококачественных мобильных игр, но после её выпуска игровая отрасль совершила ещё один серьёзный переход. Начали возникать игры в виртуальной реальности, и мы тоже захотели в этом участвовать.

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

---

Создание игрового процесса от третьего лица в VR

Как мы подошли к VR и почему вид от третьего лица?

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

Поэтому мы рассмотрели разные варианты и решили перейти к игре от третьего лица. Мы воспринимали её почти как внетелесный опыт (или ощущения Лакиту с камерой в Super Mario 64). Нашими основными отправными источниками были такие старые шедевры survival horror, как Resident Evil и Alone in the Dark. В этих играх камера фиксирована и её положение изменяется в зависимости от движения игрока (обычно при смене комнаты или зоны).



Но игра Theseus должна была стать и эмоциональным, и кинематографическим опытом. Как передать эти чувства с помощью только фиксированных камер? Это невозможно, поэтому мы решили добавить ещё одну систему следующих за персонажем камер, скопированную из более современных игр (например, из The Last of Us), но адаптировать её под VR.

Вот так мы создали нашу смешанную систему камер (Mixed-Camera System), которая позволяет нам переходить от фиксированных к следящим камерам и наоборот, в зависимости от игрового процесса. Более того, переключение происходит без каких-либо проблем с укачиванием. Если взять для примера недавние VR-игры, то можно описать эту систему как переключение между камерами Chronos и Edge of Nowhere.

---

3. Система камер

Как мы перешли к разработке системы камер

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

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

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



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

Правильный дизайн


Правильное расположение камеры. При переключении от A к B и наоборот камера учитывает положение головы игрока.

Результат в игре



Неправильный дизайн


Неправильное расположение камеры. При переключении от A к C игрок не может видеть персонажа.

СЛЕДЯЩИЕ КАМЕРЫ

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

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

ПЕРЕХОДЫ КАМЕРЫ

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

1. Мы пытались привязать любой переход к архитектурному элементу, например, к двери или входу в огромный коридор, чтобы пользователь «ожидал» переключения камеры.
2. При выполнении переходов мы снижаем скорость персонажа, чтобы запретить быстрое движение персонажа в следящей камере.
3. Перед переключением на следящую камеру мы создаём схему уровня таким образом, что игрок мотивирован двигать головой и возвращаться к нейтральному неподвижному положению (см. пример).

Правильный дизайн


A — фиксированная камера, B — следящая камера. A находится в правильном положении.


Результат в игре (переход от фиксированной к следящей камере)


Результат в игре (переход от следящей к фиксированной камере)

Неправильный дизайн


C — фиксированная камера, B — следящая камера. C находится в неправильном положении.

---

4. UI в пространстве мира

Ограничение превращается в возможность

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

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

1. В «пространстве головы» — текст всегда находится перед игроком, даже когда он поворачивает голову;
2. В «пространстве мира» — текст располагается в трёхмерном окружении.

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

• Нельзя одновременно отображать слишком много текста;
• Чтение двух строк (одна под другой) может быть неудобным;
• Необходимость смотреть на текст отвлекает игрока от других происходящих действий, что разрушает чувство погружения;
• С другой стороны, игрок может запросто пропустить субтитры, если его внимание отвлечёт что-то другое.

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



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

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

---

5. Заключение

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

Надеемся, этот пост поможет вам или вдохновит в процессе разработки для VR. Спасибо за чтение!

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

https://habrahabr.ru/post/330322/

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

@BenchmarkMode(Mode.Throughput)
@Fork(1)
@State(Scope.Thread)
@Warmup(iterations = 10, time = 1, batchSize = 1000)
@Measurement(iterations = 40, time = 1, batchSize = 1000)
public class Chaining {

    private String a1 = "111111111111111111111111";
    private String a2 = "222222222222222222222222";
    private String a3 = "333333333333333333333333";

    @Benchmark
    public String typicalChaining() {
        return new StringBuilder().append(a1).append(a2).append(a3).toString();
    }
    
    @Benchmark
    public String noChaining() {
        StringBuilder sb = new StringBuilder();
        sb.append(a1);
        sb.append(a2);
        sb.append(a3);
        return sb.toString();
    }

}

Результат:

Benchmark                  Mode  Cnt      Score      Error  Units
Chaining.noChaining       thrpt   40   8408.703 ±  214.582  ops/s
Chaining.typicalChaining  thrpt   40  35830.907 ± 1277.455  ops/s

Итого, конкатеницая через цепочку вызовов sb.append().append() в 4 раза быстрее… Автор из статьи выше утверждает, что разница связана с тем, что в случае цепочки вызовов генерируется меньше байткода и, соответственно, он выполняется быстрее.
Ну что ж, давайте проверим.

Разница в байткоде?

Гипотезу можно легко проверить без углубления в байт код — создадим типичный UriBuilder:

public class UriBuilder {

    private String schema;
    private String host;
    private String path;

    public UriBuilder setSchema(String schema) {
        this.schema = schema;
        return this;
    }

   ...

   @Override
   public String toString() {
       return schema + "://" + host + path;
   }
}

И повторим бенчмарк:

@BenchmarkMode(Mode.Throughput)
@Fork(1)
@State(Scope.Thread)
@Warmup(iterations = 10, time = 1, batchSize = 1000)
@Measurement(iterations = 40, time = 1, batchSize = 1000)
public class UriBuilderChaining {

    private String host = "host";
    private String schema = "http";
    private String path = "/123/123/123";

    @Benchmark
    public String chaining() {
        return new UriBuilder().setSchema(schema).setHost(host).setPath(path).toString();
    }

    @Benchmark
    public String noChaining() {
        UriBuilder uriBuilder = new UriBuilder();
        uriBuilder.setSchema(schema);
        uriBuilder.setHost(host);
        uriBuilder.setPath(path);
        return uriBuilder.toString();
    }

}

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

Результат:

Benchmark                       Mode  Cnt      Score      Error  Units
UriBuilderChaining.chaining    thrpt   40  35797.519 ± 2051.165  ops/s
UriBuilderChaining.noChaining  thrpt   40  36080.534 ± 1962.470  ops/s

Хм… Разница на уровне погрешности. Значит количество байткода тут ни при чем. Так как аномалия проявляется со StringBuilder и append(), то наверное это как-то связано с известной JVM опцией +XX:OptimizeStringConcat. Давайте проверим. Повторим самый первый тест, но с отключенной опцией.

В JMH через аннотации сделать это можно так:
@Fork(value = 1, jvmArgsAppend = "-XX:-OptimizeStringConcat")

Повторяем первый тест:

Benchmark                  Mode  Cnt     Score     Error  Units
Chaining.noChaining       thrpt   40  7598.743 ± 554.192  ops/s
Chaining.typicalChaining  thrpt   40  7946.422 ± 313.967  ops/s

Бинго!
Так как соединение строк через x + y довольно частая операция в любом приложении — Hotspot JVM находит new StringBuilder().append(x).append(y).toString() паттерны в байткоде и заменяет их на оптимизированный машинний код, обходясь без создания промежуточных объектов.
К сожалению, эта оптимизация не применяется к sb.append(x); sb.append(y);. Разница на больших строках может быть на порядок.

Выводы

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

Вопрос на SO
Связанный доклад с грязными подробностями от Шипилева.

https://habrahabr.ru/post/330220/

Как это ни странно, даже сейчас, спустя столько десятилетий, есть множество людей, которым интересен ZX-Spectrum. И дело не ограничивается программными эмуляторами, нет. У этих людей есть вполне себе настоящие, “железные” спектрумы. Подавляющее большинство этих компьютеров оснащено дисководами, но есть и экземпляры только с магнитофонным входом. Такой компьютер можно загрузить, например, с аудиоплейера. Но при таком способе загрузки неудобно переходить между блоками данных внутри аудиофайла, например, если игра требует загрузки уровней. Да и места аудиофайлы занимают порядочно… Есть, конечно, ещё разные программы для смартфонов, воспроизводящие форматы файлов данных для спектрума tap и tzx. Но можно для этих же целей собрать аппаратный эмулятор магнитофона, описанный в этой статье.

Описываемый эмулятор собирается на базе микроконтроллера atmega16 и способен воспроизводить tap-файлы, лежащие на SD-карте. Записывать на SD-карту файлы он не умеет (да мне это и не требовалось).


Внешний вид эмулятора магнитофона в моём исполнении.

Схема эмулятора представлена на рисунке ниже.


Схема эмулятора магнитофона.

В схеме использован дисплей 1602, микроконтроллер atmega16 и динамическое ОЗУ MB81C4256. Зачем нужно ОЗУ в таком эмуляторе, ведь можно последовательно считывать два блока (один читаем, другой выводим) с карты памяти? Да, можно. Но применение большого ОЗУ упрощает программу – все выводимые данные целиком находятся в ОЗУ, и достаточно просто последовательно их читать и выводить. Кроме того, наличие ОЗУ позволяет разогнать скорость вывода сигнала практически до максимальной для ZX-Spectrum. Это, правда, потребует существенной модификации программы загрузки в ПЗУ спектрума. В данном эмуляторе максимальная скорость вывода данных в четыре раза больше, чем стандартная скорость загрузки спектрума. То есть, требуется модифицированное ПЗУ. Прошивки такого модифицированного ПЗУ представлены в архиве.

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

Магнитофонный сигнал с ZX-Spectrum представляет собой частотно-модулированный сигнал, при этом самой высокой частотой закодированы ноль и синхросигнал (частота синхросигнала чуть выше, чем у ноля). Частотой в 2 раза ниже частоты ноля закодирована единица. Частотой в 2.5 раза ниже частоты ноля закодирован пилот-тон (звуки пи-и-и-и-и в начале загрузки). На рисунке показан формат сигнала в тактах процессора Z80 (частота в ZX-Spectrum 3.5 МГц, если кто забыл). Сначала идёт длительный (несколько секунд) пилот-тон, затем следует синхросигнал, а после него уже выдаются данные.


Формат магнитофонного сигнала ZX-Spectrum.

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

Вот видео работы эмулятора магнитофона:


А вот работа на скорости 4x:


В архиве прошивка, исходники прошивок, печатная плата, схема, прошивка ПЗУ ZX-Spectrum для скоростей 4x и 2x, программа конвертации TAP в WAV и программа обратной конвертации из WAV в TAP.

https://habrahabr.ru/post/330752/

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

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

Электронная почта — один из старейших сетевых сервисов. Появилась она в 1982 году, а ведь в то время вопросы безопасности в Интернете стояли не так остро, как сейчас. Если верить исследованиям компании Mimecast, около 94% опрошенных компаний полностью бессильны в борьбе с утечкой информации через электронную почту.

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

Ведь стоит это недорого, а работает надежно.

Что вы можете сделать для защиты электронной почты?

В прошлой статье «Как при помощи токена сделать Windows домен безопаснее? Часть 1» мы рассказали, как настроить безопасный вход в домен. Напомнили, что такое двухфакторная аутентификация и каковы ее преимущества.

В этой статье мы поговорим о защите электронной почты.

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

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

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

Как работает протокол S/MIME?

Протокол S/MIME (Secure/Multipurpose Internet Mail Extensions) обеспечивает аутентификацию, целостность сообщения, сохранение авторства и безопасность данных.

S/MIME идентифицирует обладателя открытого ключа с помощью сертификата X.509.

S/MIME обеспечивает защиту от трех типов нарушений безопасности:

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

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

Однако цифровая подпись сама по себе не гарантирует передачу сообщений с обеспечением конфиденциальности. В S/MIME эту функцию выполняет шифрование. Грубо говоря, оно осуществляется с помощью асимметричного криптографического алгоритма.

Спецификация S/MIME определяет два типа файлов в формате MIME: один для цифровых подписей, другой для шифрования сообщений. Оба типа базируются на синтаксисе криптографических сообщений стандарта PKCS#7.

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

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

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

На рисунке показаны этапы шифрования сообщения электронной почты в S/MIME:

1. Алиса создает сообщение, которое она хочет зашифровать и отправить Бобу. Решает его отправить Бобу. Клиент обмена сообщениями, видя, что письмо нуждается в шифровании, генерирует случайный ключ шифрования (закрытый ключ, который обычно называется сеансовым ключом, впоследствии новый случайный ключ генерируется каждый раз, когда отправляется зашифрованное сообщение) и зашифровывает с его помощью сообщение.
2. Сеансовый ключ шифруется с помощью открытого ключа получателя и прикрепляется к сообщению, а это значит, что расшифровать его может только закрытый ключ Боба.
3. Зашифрованный текст и зашифрованный ключ отправляются Бобу посредством SMTP (Simple Mail Transfer Protocol).
4. Почтовый клиент Боба использует закрытый ключ Боба для расшифровки зашифрованного ключа и получает расшифрованный сеансовый ключ. Здесь гарантируется секретность, т. к. для расшифровки сеансового ключа, необходимого для расшифровки сообщения, может быть использован только закрытый ключ Боба.
5. Почтовый клиент Боба использует расшифрованный сеансовый ключ для расшифровки почтового сообщения, результатом этого является расшифрованное исходное сообщение, которое было отправлено Алисой.

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

На рисунке показаны этапы аутентификации и обнаружения подделки сообщения с использованием электронной подписи:

1. Алиса создает сообщение и подписывает его электронной подписью. Почтовый клиент видя, что сообщение должно быть подписано, генерирует хеш сообщения Алисы (в результате получается хеш d — «digest»).
2. Хеш подписывается клиентом обмена сообщениями с использованием закрытого ключа Алисы. Это означает, что только ее открытый ключ будет способен проверить подпись на этом хеше.
3. Подписанный хеш вместе с сообщением отправляется Бобу.
4. Почтовый клиент Боба использует открытый ключ Алисы для проверки подписи хеша и убеждается, что подпись на хеше правильная.
5. Почтовый клиент Боба вычисляет новый хеш на основе отправленного Алисой текста (результат в хеше d).
6. После этого почтовый клиент Боба сравнивает проверенный хеш и заново вычисленный в пункте 5. Это позволяет узнать Бобу, является ли цифровая подпись действительной. Если два хеша одинаковые, то сообщение действительно пришло от Алисы и не было подделано в процессе передачи.

Microsoft Outlook и другие почтовые клиенты для шифрования и подписания электронных писем используют протокол S/MIME. Если получатель и отправитель зашифрованного электронного письма используют разные почтовые клиенты, то это не означает, что они не смогут читать зашифрованные письма друг друга. Мы для примера рассмотрим процесс настройки почтового клиента Microsoft Outlook, как наиболее распространенного в корпоративной среде. Другие почтовые клиенты тоже можно использовать для шифрования и подписи сообщений. Их настройка в целом похожа, но могут быть нюансы.

Как настроить защиту сообщений в Microsoft Outlook с помощью Рутокен ЭЦП PKI?

А теперь за дело. Настроим шифрование и подписание писем.

Для примера я буду использовать устройство для безопасного хранения ключей и сертификатов Рутокен ЭЦП PKI .

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

Для начала, используя панель Рутокен, сохраните сертификат в локальном хранилище и установите для него параметр «по умолчанию».

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

В Microsoft Outlook выберите пункт меню «Файл» и подпункт «Параметры».

Выберите пункт «Центр управления безопасностью» и нажмите «Параметры центра управления безопасностью...».

Выберите пункт «Защита электронных писем» и установите необходимые флажки.

Нажмите «Параметры».

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

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

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

Мы отправим подписанное письмо.

Для подписания письма электронной подписью перейдите на вкладку «Параметры» и нажмите «Шифрование» (чтобы письмо было только подписано). Все просто!

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

Иногда необходимо подписать только файл, приложенный к письму. Это можно сделать, подписав сам файл в одном из популярных приложений Microsoft Word или Microsoft Excel.

Мы рассмотрим процесс подписания файла в приложении Microsoft Word.

Как подписать файл в Microsoft Word?

Защитить файл от изменений можно с помощью электронной подписи.

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

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

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

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

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

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

Давайте для примера подпишем любой документ в формате DOCX.

Я буду использовать приложение Microsoft Word 2016.

Вам потребуется токен или смарт-карта. Я для примера буду использовать Рутокен ЭЦП 2.0.

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

Выберите пункт «Файл» и нажмите «Защита документа».

Выберите пункт «Добавить цифровую подпись».

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

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

Нажмите «Изменить» и выберите необходимый сертификат.

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

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

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

Резюмируем

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

• отправлены именно вами;
• прочитаны только выбранными получателями;
• защищены от изменений при передаче;
• созданы и подписаны именно вами.

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

https://habrahabr.ru/post/329904/

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


«Два типа людей в эксплуатации: кто уже сломал production, кто ещё только собирается это сделать»

Опубликованная 10 дней назад заметка собрала более 23 тысяч положительных голосов на Reddit и разошлась по другим специализированным ресурсам вроде The New Stack. Суть истории такова:

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

Мне дали документ с информацией о том, как настроить локальное окружение для разработки. Инструкции включают запуск маленького скрипта для создания личной копии БД с тестовыми данными. После запуска определённой команды я должен был скопировать URL/пароль/юзера базы данных из её вывода и настроить dev-окружение, указав там эту базу. К сожалению, вместо копирования данных нужной команды я по какой-то причине использовал значения из самого документа.

К несчастью, оказалось, что указанные там значения — от базы данных в production (не знаю, почему они задокументированы в инструкции по настройке dev-окружения). Далее, как понимаю, тесты добавили ненастоящие данные и очистили существующие, то есть между запусками тестов все данные из БД в production были удалены. Честное слово, не имел представления, что я сделал, а чтобы это выяснить/осознать, кому-то из коллег потребовалось даже не полчаса.

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

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


«Бэкап Шрёдингера: состояние любого бэкапа остаётся неизвестным, пока его не попробовали восстановить»

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

Проведённый на The Register опрос среди 13+ тысяч пользователей показал, что младшего разработчика считают правильно уволенным всего около 1 % человек, а вот уволить CTO захотели 47,5 % интернет-пользователей. А как думаете вы?

P.S. В комментариях Reddit указывают на похожую историю в Amazon, случившуюся в 2012 году, и, конечно, ещё весьма свежий кейс с GitLab.

P.P.S. Назначение этой публикации — напомнить об очевидном:

1. Уделяйте должное внимание выстраиванию важных процессов и документированию.
2. Не забывайте про бэкапы (и восстановление из них).
3. Даже в стрессовых ситуациях сохраняйте адекватность по отношению к людям.

https://habrahabr.ru/post/330750/

https://habrahabr.ru/post/329262/

Приглашаем принять участие в DevConf::BackEnd в эту субботу, в центре внимания: PHP 7.1, слабости сетевого API в ядре Linux, чат-боты, живые видео-трансляции, системы обработки событий и Haskell.

Открывает конференцию интересный доклад Валентина Бартенева — участника команды разработки Nginx. Он будет ругать линукс — точнее, сетевой API ядра для userland-приложений, и жаловаться на жизнь нелегкую, многопоточную мультиплексируемую.

Александр Макаров, один из авторов фреймворка Yii, расскажет о том, куда идем мы с PHP 7.1 Артем Дехтярь и Павел Степанец будут рассказывать PHP-шникам о неравной борьбе с legacy. Иван Матвеев убедит вас писать на PHP то, что можно еще и прочитать. А для тех, кто любит модное, стильное и странное, Дмитрий Зуйков расскажет про web-разработку на Haskell.

Модной темой остаются чат-боты для телеграмма. В прошлом году платформу для ботов представляли на стеках Microsoft и Ruby, а в этом году догонять решили на PHP, Python и Rust. Владимир Юлдашев и Антон Шрамко будут учить нас использовать API Telegram полностью и правильно.

Тяжелой артиллерией в этом году выступают Ефим Пышнограев из Яндекс, Александр Сербул из 1С-Битрикс, и Алексей Акулович из Вконтактика. Мы услышим увлекательные и поучительные истории про обработку миллиардов рублей, то есть, событий в AppMetrica, про живые видео-трансляции, и приручение Amazon кластером битриксов.

Партнеры конференции DevConf'17: Альфа-Лаборатория, MediaSoft, Selectel, Reg,Ru, Lamoda, YiiConf, JoomlaDay, Postgres Professional, PGDAy, Lua in Moscow, ElixirLangMoscow, Frontend Weekend, PHPClub.ru, Meetup.com

До встречи на конференции сообществ разработчиков!

https://habrahabr.ru/post/330748/

Продолжая отдавать должное вопросам психологии в процессе тестирования, мы можем определить набор витальных (читай, чертовски жизненных) принципов тестирования. Многие из них покажутся очевидными, что, однако, не мешает зачастую ими пренебрегать. Вот они, а дальше – подробное их рассмотрение:
1. Обязательная часть тестирования – определение ожидаемого результата;
2. Программистам следует избегать тестирования их собственных программ (и участков кода);
3. Организациям, создающие программы, следует избегать тестирования их собственных программ;
4. Процесс тестирования должен включать в себя тщательную проверку результатов каждого теста;
5. Тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых;
6. Исследование Системы на предмет того, что она не делает того, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает;
7. Избегайте одноразовых тест-кейсов, только если сама программа не является одноразовой. Одноразовые тест-кейсы для одноразовых программ. В остальных случаях следует избегать таковых;
8. Не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок;
9. Вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок;
10. Тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие.

Принцип 1: обязательная часть тестирования – определение ожидаемого результата

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

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

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

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

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

Принцип 4: процесс тестирования должен включать в себя тщательную проверку результатов каждого теста

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

Принцип 5: тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых

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

Принцип 6: исследование Системы на предмет того, что она не делает, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает

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

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

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

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

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

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

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

Принцип 10: тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие

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

https://habrahabr.ru/post/330746/

На днях мне довелось провести практическое занятие по программированию для учеников десятого класса одного из харьковских лицеев. Шесть лет назад я читал курс программирования в политехе, но тогда на посвящение студентов в эту, не побоюсь сказать, науку у меня было целых два семестра времени на лекционные и лабораторные занятия. А здесь было всего от силы полтора часа, да и с таким юным контингентом я ещё не работал. «Ладно», сказал я себе. И приступил к подготовке. Мне дали несколько задач, которые можно было бы порешать со школьниками. Первая из них занимала аж 70 строк индусского кода. Подготовил своё решение из 10 строк. Думал, «Сначала дам одно решение, потом покажу другое». Ещё одну задачу переписал для того, чтобы сместить акценты с программистских особенностей в предметную область (задача была геометрическая). Третья задача была наиболее простой – один человек вводит с клавиатуры число, другой отгадывает. Неинтересно. Пусть лучше компьютер загадывает и даёт подсказки. Для каждой задачи придумал последовательность подачи материала. Когда пришло время, а школьники расселись за компьютеры, я их спросил: «Кто-нибудь из вас имеет опыт программирования? Какие-то языки программирования уже изучали?». Получив отрицательный ответ, мысленно сказал себе «Печально», отложил в сторону два листа с распечаткой кода из трёх и сделал заявление: «Ну, что ж… Тогда начнём программировать!».

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



Вводное слово о программировании началось примерно так. «Компьютеры сейчас применяются практически в любой сфере человеческой жизни. Поэтому неважно, какой путь вы выберете, на кого станете учиться, уметь программировать достаточно важно. С помощью этой науки можно получить существенную выгоду». Далее я привёл пример «задаче о коммивояжёре», сформулировав её следующим образом: «Представьте, что вы работаете в Новой Почте. Вам нужно доставить множество посылок в разные города. Хорошо бы выбрать путь, чтобы был бы как можно короче. Это сэкономит деньги – курьер работать будет меньше часов, бензина потратите меньше литров». И небольшой переход: «Но, к сожалению, компьютер сам не умеет решать такие задачи. Он умеет выполнять лишь арифметические и логические операции» (ну, и другие, но не будем сейчас об этом). «Причём делает он это над числами в виде нулей и единиц» (не будем тратить время, рассказывая о двоичной системе счисления – надеюсь, в школьной программе она есть). «Команды компьютеру (машинные инструкции) тоже даются в виде чисел. Но обычно программисты пишут программы на языках, понятных человеку – например, C, Java, C++». Услышав «си-плюс-плюс», дети оживились. «Чтобы преобразовать код программы в команды компьютеру есть несколько видов программ, например, компиляторы. Чтобы более удобно с ним работать будем использовать другую программу – среду разработки, которая также включает текстовый редактор и много других полезных инструментов. Найдите на рабочем столе ярлык программы Code::Blocks и запустите его».

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



«Итак, можно увидеть, что в коде программы встречаются английские слова. Это и include, и using, и main, и return. В первой строке мы включаем, т.е. используем, некую библиотеку. Обычно программисты используют код, написанный другими программистами. Он включается во всевозможные библиотеки. В данном случае мы используем библиотеку iostream. Здесь i – это input (ввод), o – output (вывод), stream – поток. Т.е. библиотека содержит код для ввода с клавиатуры и вывода на экран» (перегружать школьников информацией о перенаправлении потоков ввода-вывода не стоит). «Если библиотек много, между ними могут возникнуть конфликты, поэтому код обычно размещают в разных пространствах. using namespace std нужно для того, чтобы выбрать пространство имён (namespace) std – сокращение от standard (стандартный). int говорит, что идёт речь о целых числах, об их хранении и передаче» (т.е. я имел в виду объявление переменных и возвращаемое функцией значение; о явном приведении типов рассказывать не стал) «main – имя функции. Функция – это какой-то логически завершённый участок кода, который возвращает какое-то значение. cout… c – console (консоль – клавиатура и экран), out – вывод, endl – end of line, конец строки. В седьмой строке происходит вывод текста, заключённого в двойные кавычки, на экран. return 0 в данном случае говорит операционной системе об успешном завершении программы».

После этого предложил нажать F9, чтобы скомпилировать программу («преобразовать текст программы в машинные инструкции»). «Поздравляю! Вы написали свою первую программу!», сказал я, когда увидел, что на мониторах появились консоли с текстом. Потом уточнил: «Ну, не совсем написали – за вас это уже сделали другие. Поэтому давайте внесём изменения в код. Измените в двойных кавычках текст Hello world! на какой-нибудь другой на английском языке и ещё раз нажмите F9. Вот теперь другое дело!». Кто-то не закрыл окно запущенной программы, поэтому компиляция не прошла. Пришлось помогать. «Теперь замените текст на какой-нибудь другой, на русском языке. И удивитесь.» Те, кто написал «Привет», увидели следующее:



«Всё дело в том, что текст тоже преобразуется в нули и единицы. И как именно будет происходить это преобразование, зависит от кодировки. Кто-нибудь сталкивался с этим понятием?» В ответ – неуверенное мычание… «Давайте зададим кодировку для кириллицы. Установим (set) соответствующую локаль (locale). Для этого седьмую строку опустим вниз (поставим курсор в начале строки и нажмём Enter). И в пустой седьмой строке введём setlocale(LC_ALL, "rus"); А во второй строке введём #include ». Кто-то LC_ALL написал строчными буквами (пришлось объяснить, что строчные и заглавные буквы отличаются), кто-то списал с доски L.C.A.L.L. (да, доска в ужасном состоянии), кто-то написал «russ» и не получил должного результата. Но в большинстве случаев я увидел положительный исход. Немного опечалил текст, который написала одна девочка, «хочу кушать». В таком состоянии восприятие информации довольно сильно страдает.

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

«Для генерации случайного числа используется функция rand, сокращение от слова random – случайный. Чтобы её использовать, нужно подключить библиотеку cstdlib. Для генерации числа от 0 до 99 нужно взять остаток от деления результата, который возвращает функция, на 100. Операция получения остатка от деления записывается символом процента». Тут пришлось напомнить школьникам, что такое остаток от деления. Привёл пример «5%2», и им стало ясно, что я имел в виду. «Результат выполнения операции взятия остатка от деления (т.е. случайное число от 0 до 99) нужно куда-то записать. Это число целое. Странно было бы, если бы мы пытались угадать какое-нибудь вещественное число, например, 2.584 или 35.763. Для хранения результата будем использовать переменную. Переменная – это область памяти компьютера (нам пока неважно, где эта память находится), к которой можно обращаться по имени». Да, с переменными различных типов можно выполнять определённый набор операций, но это сейчас не имеет значения. «Назовём переменную u (от слова unknown). Для объявления переменной целого типа используется слово int. Такая область памяти на этих компьютерах занимает 4 байта и может вместить число примерно от минус двух до плюс двух миллиардов. Этого достаточно?» Получив утвердительный ответ, написал на доске недостающий код. Получилось следующее (вместе с исправлением вывода – теперь на экране будет не текст, а значение переменной):



Запустив программу, школьники, все до одного, увидели число 41. Не 42, но тоже сойдёт. Причём результат не изменялся от запуска к запуску. «Итак, мы получили случайное число. Действительно, кто бы мог подумать, что компьютер выдаст 41? Число 41 удовлетворяет условиям, которые мы поставили. Оно находится в интервале от 0 до 99. Но как его сделать действительно случайным? Для этого нужно задать так называемое зерно генератора случайных чисел, например, текущим временем. Добавьте перед десятой строкой строку srand(time(0)); Если программа не компилируется – добавьте библиотеку ctime»
Теперь программа выдавала действительно случайные (ну, на самом деле не случайные, но это для этой задачи значения не имеет) числа. Исходник программы на данный момент был таким:



Осталось написать код, отвечающий за его угадывание.

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



«В тринадцатой строке мы объявили переменную i (от input), аналогичную переменной u. В ней мы будем хранить введённое число. Собственно ввод осуществляется в 16-й строке. Цикл объявляется ключевым словом do. Всё, что заключено в фигурные скобки, будет повторяться пока (while) значение переменной i не равно u». Что касается этого участка кода, то типичные ошибки учеников были такие. Во-первых, они ставили вместо фигурных скобок круглые. Во-вторых, операцию сравнения «!=» писали раздельно. После компиляции программы дети настойчиво пытались отгадать число u. Меня поразило, что девочка, которая ранее написала «хочу кушать» делала это весьма успешно. Из ошибок времени исполнения я был рад увидеть следующую:



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

Мы подошли к финишной прямой. Осталось добавить подсказки. Я написал на доске два «if-а» и пояснил. «Если введённое число больше загаданного, выводим соответствующее сообщение (строка 17). Если введённое число меньше загаданного – делаем так же (строка 18).» Плюс ко всему я расширил вывод сообщения о завершении «игры».



Это был окончательный текст программы, которую набрал на первом уроке программирования 10-в класс. Программа далеко не идеальна. В частности, мне не нравятся сообщения «Ваше число больше!» и «Ваше число меньше!». Они реально запутывают. Если бы у меня был второй шанс провести подобный урок, сформулировал бы по-другому.

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



Итоги подведём.

1. Урок прошёл успешно. Все ученики справились с заданием. Задача решена. Всего одна, но решена. Не без трудностей, конечно.

2. Я получил новый опыт преподавания. Последние два года читаю лекции и провожу лабораторные работы только студентам пятого курса, а работать с ними – совершенно иное дело. У них уже есть какая-то база, отношение к учёбе (да и к жизни в целом) другое, а мои предметы узко специализированные – материал, который я даю, в будущем пригодится от силы 2–3 нашим выпускникам из каждой группы. Здесь же есть надежда, что именно этот урок вызовет интерес к программированию у одного-двух учеников.

3. Школьная учебная программа совершенно иная, нежели та, по которой учился я. Да, я ходил не в простую школу. В седьмом классе мы изучали Logo, в восьмом – BASIC, а в девятом – Pascal. Но, тем не менее, даже тем моим одноклассникам, которые не блистали знаниями по другим предметам (а ведь и я тоже не блистал!), информатика нравилась. Я уверен, что давать программирование в школе нужно обязательно. Оно отлично развивает мозг и позволяет понять компьютеры (без которых мы уже не представляем свою жизнь) совершенно с другой стороны.

4. Язык C++ имеет высокий порог вхождения. Одного урока, чтобы раскрыть основы этого языка программирования, явно недостаточно. Да, я не знаю C++. Я обожаю C, а когда мне нужно ООП, я пишу на Java. Но изучать C++ в вузе скорее всего нужно (C по моему скромному мнению – обязательно). Опять же многое зависит от вуза и специальности.

Спасибо за внимание всем, кто прочёл до конца! Буду рад ответить на ваши вопросы.

P.S. Есть идея написать ещё одну статью об информатике в школе. Если поддержите в комментариях, статья, скорее всего (не буду обещать), увидит свет.

https://habrahabr.ru/post/330744/

Что общего у этой картинки, Excel и прикладной работы с базами данных? Правильно — байесовский подход к анализу данных.

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

0. Немного теории

In a nutshell, простыми словами, байесовы модели — это набор вероятностных распределений (пардон за термины), которые соединены стрелочками (ужасно звучит, но самое простое объяснение такое). В классических байесовых моделях стрелочки имеют направленность (в цепях Маркова — направления нет).

Тут также репостил ссылку про визуализацию условной байесовой вероятности.


Определение от профессора.

Если разбить модель на пальцах на составляющие, то по сути она состоит из:

1. Безусловных вероятностных распределений (сумма весов в таблице равна единице) определенных случайных величин (сложность, интеллект, оценки из примера ниже);
2. Условных распределений случайных величин, которые зависят от других;
3. Правил, по которым можно работать с такими моделями, причинно-следственных связей и аксиоматики (смотрите курс выше);

Меньше слов — больше дела. Вот пояснение in a nutshell.
Более сложная модель на примере Симсонов.


Более приближенная к реальности модель

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

1. Немного логики

Пример 1 — причинно следственная связь (примеры их курса) или индукция (в математике стрелочка вправо =>). Вероятность, что у вас будет положительный отзыв (letter) при прочих равных равна примерно 50%. Если при этом вы не очень умны, то она падает до 39%. Если при этом курс простой — то вероятность опять повышается до 51%. Все это кажется простым и логичным.


Пример 2 — дедукция (решение на основе неких данных, или стрелочка влево <=). Если студент получил тройку, то вероятность того, что он не очень умный растет, а вероятность того, что курс сложный — тоже растет.


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

2. Немного практики

Еще пара слов, почему такие модели редко применяются в ЧИСТОМ виде в реальности:

• Количество параметров такой модели весьма высоко, и зачастую выше, чем число переменных;
• Требуется большое количество статистики по прошлым распределениям, что есть далеко не в каждой области знаний;
• Зачастую нельзя наблюдать непосредственные переменные, а можно только наблюдать логи действий людей. В описанной выше модели наблюдение оценки и сложности может заменить наблюдение интеллекта, но это все вилами на воде писано;
• Если при использовании линейной модели есть статистические тесты на значимость, а при использовании machine learning алгоритмов есть валидационная и тестовая выборка, то при использовании байесовых моделей по сути априори сразу требуется глубокое знание предметной области и много данных;
• С другой стороны — по сути любая регрессия или нейронная сеть, по логике своей является простой байесовой моделью, где закреплена некая структура данных;

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

Представьте, что есть некая база данных, где компания собирает 3 вещи — имя, адрес почты человека и его IP адрес. 99% веб-сервисов могут получить доступ к такой статистике. Представьте, что компания является глобальной и не имеет ограничений по географии своих клиентов и стоит задача определить язык, на котором говорит каждый человек с высокой степенью вероятности за очень краткий срок.

Конечно в идеальном мире можно было бы сделать так (в скобках пишу почему не подходит):

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

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

1. Выделяем почтовый домен из адреса почты (aveysov@gmail.com => gmail.com);
2. Все ярко национальные сервисы (типа qqq или 123 в китае, mail.ru в России и тому подобное) — очень сильно говорят, что человек говорит на языке сервиса даже невзирая на имя человека или страну его последнего;
3. Из оставшегося выбираем национальные субдоменты типа yahoo.de или просто национальные домены. Условная вероятность, того, что человек говорит по-немецки даже если у него последняя страна захода — США — гораздо выше, чем если у него просто страна захода — Германия;
4. Из оставшегося проставляем языки для очевидных стран, где точно преобладает один государственный язык;
5. Остаются страны с большим числом языком или просто очень многонациональные / многоязыковые страны;
6. В таком случае в идеале дальше надо найти вектора, которые бы говорили как распределены имена по языкам, но такой статистики я быстро не смог найти и просто остановился на самом популярном языке для страны оставшихся пользователей;

3. Немного красоты

Это все прекрасно, но как сейчас проверить, что наша примитивная модель сработала? Очень просто — посмотреть на имена людей с заданным языком. Язык — как правило статистически свойство культуры (людей, которые имеют сразу 2-3 родных языка и национальности очень мало). Можно построить просто вектора вероятностей, а можно построить красивые картинки.

Арабский язык


Немецкий язык


Греческий язык


Португальский язык

Испанский язык


Китайский язык


Словенский язык


Венгерский язык


Французский


Хинди


Польский язык


Русский язык


Чешский


И внезапно английский язык (объяснение простое — если убрать страны юго-восточной Азии, то все встает на свои иместа)


Английский без стран юго-восточной Азии


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

https://habrahabr.ru/post/330732/

https://habrahabr.ru/post/330738/

И про то, что у кур тоже бывают психи.

Птица beauty в гнезде

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

Статьи про нейрокурятник

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

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

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

• Вываливаю список файлов за день в консоль.
• Закидываю список в Calc/Excel.
• Вытягиваю из имени файла дату и время создания.
• Сортирую по времени.
• Нахожу в дампе файл, открываю, проставляю идентификатор объекта (в таблицу).
• По окончании разметки заливаю файл в базу.

Что такое идентификатор объекта?

Объект — это курица, отсутствие чего-либо вообще, две курицы, яйцо, два яйца, отсутсвие света или что-то совсем нерелевантное (чья-то рука, ворующая яйца динозавров, привидения, кошка) и т.д. Идентификатор объекта — просто уникальный номер в базе. Например, 14 — это курица psycho, -1 — отсутствие света, 0 -отсутсвие чего-либо, 10 — восемь яиц в гнезде. У объектов есть атрибуты, например, пестрота спинки и воротничка, основной цвет. У атрибутов есть выраженность.

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

Сначала я засела за pgAdmin и честно делала все через sql, что не сильно отличается от сидения в консоли бд, поэтому в какой-то момент я все-таки поставила себе вайн и открыла навикат. Все-таки так удобнее и быстрее, хотя бывает нужно добавить забытый sequence или constraint или удалить лишний, придется все равно открывать доку и писать запрос). И csv-шки потом проще заливать. Хотя можно составить формулами в excel запросы на инсерт, так я тоже делаю, да =)

Все это вылилось в малюсенькую er-диаграмму:

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

Главная таблица в схеме — chicoopfiles. Это соотнесение файла и объекта. Так как файлу соответсвует всего один объект, я заношу объекты в таблицу с файлами сразу.

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

Это psycho в гнезде

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

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

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

Любопытство

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

В таком случае получаем иногда трудноразличимых кур. У нас это куры red star и red twin. Это две красные курицы, одна из которых получила прозвище Звезда Интернета, потому что некоторое время я использовала ее фото в качестве аватарки, родителей это позабавило и теперь курица носит такое прозвище. Вторая просто очень на нее похожа. На фотографиях их можно различить по темным пятнам. У Звезды более пестрый воротник и темные пятна на плечах, у ее подруги более темное пятно на спине у воротника.

Слева — red star, справа — red twin

Ну и немного про ручных наглых кур и как они чуть не сожрали меня.

https://habrahabr.ru/post/330740/