Это четвёртая из пяти частей туториала, посвящённого созданию игр с помощью Python 3 и Pygame. В третьей части мы углубились в сердце Breakout и узнали, как обрабатывать события, познакомились с основным классом Breakout и увидели, как перемещать разные игровые объекты.

(Остальные части туториала: первая, вторая, третья, пятая.)

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

Некоторые из вас, возможно, слышали, что в первую неделю декабря по всей России прошла образовательная акция “Час кода": для школьников 5-11 классов проводили открытые уроки, на которых показывали, что программировать это просто и увлекательно и каждый может этому научиться.



Мы в Acronis решили поделиться собственным опытом: как мы пробуем обучать программированию наших сотрудников, не отрывая их от работы.

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

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

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

Продолжаю вещать на тему прояснения основных представлений об FC SAN. В комментариях к первому посту меня попрекнули тем, что копнул недостаточно глубоко. В частности — мало сказал о непосредственно FC и ничего о BB credits, IP и multipathing. Multipathing и IP — темы для отдельных публикаций, а про FC, пожалуй, продолжу. Или начну, как посмотреть.

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

Fibre or Fiber?: Изначально технология Fibre Channel предполагала поддержку только волоконно-оптических линий (fiber optic). Однако, когда добавилась поддержка меди, было принято решение название в принципе сохранить, но для отсылки на стандарт использовать британское слово Fibre. Американское Fiber сохраняется преимущественно для отсылки на оптоволокно.

Оригинал

Fibre Channel was originally designed to support fiber optic cabling only. When copper support was added, the committee decided to keep the name in principle, but to use the UK English spelling (Fibre) when referring to the standard. The US English spelling (Fiber) is retained when referring generically to fiber optics and cabling.

IBM Redbook «Introduction to SAN and System Networking»

Начало

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

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

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

Иллюстраций: 34, символов: 51 609.

Часть 2
Часть 3
Часть 4

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

Статья рассчитана на специалистов, имеющих опыт работы с построением IVR в Asterisk и имеющих представление о системах голосового самообслуживания.

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

Привет, Хабр. Обычно я пишу программы для неговорящих людей, но решил удариться в крайности и сделать продукт для говорящих людей. Я хочу рассказать о разработке бота для VK, который переводит пересланные ему голосовые сообщения в текст. Сначала я использовал Yandex SpeechKit, но потом уперся в дневной лимит распознаваемых единиц и перешел на wit.ai, об этом и хочу рассказать, а также о фреймворке для создания ботов vk с помощью node.js, болтовне гугловского dialogflow.

Часть первая: Meltdown.

Несмотря на всю мощь уязвимости Meltdown, принесённое этим Новым годом счастье не было бы полным, если бы не вторая часть открытия, не ограничивающаяся процессорами Intel — Spectre.

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

Строго говоря, Spectre не является одной уязвимостью — уже на старте заявлены два различных механизма (CVE-2017-5753 и CVE-2017-5715), а авторы отмечают, что может быть ещё и много менее очевидных вариантов.

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

Да, я знаю, что это уже третий материал на GT/HH по данной проблеме.

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

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

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

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

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

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

Думаю, почти каждый сталкивался с проблемой печати больших pdf файлов. Недавно и мне пришлось напечатать мануал в 600 страниц. Так как документ целиком состоит из текста не очень то хотелось печатать все 300 листов а4. В поисках решения наткнулся на статью от rapkasta.

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

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

Уже 2 месяца использую на своих компьютерах модуль zRam и хочу поделиться результатами. На практике он позволил мне не используя раздел подкачки, и не получая видимого замедления работы компьютера увеличить размер оперативной памяти в 2.5-3 раза. На сервере виртуалок тот же подход позволил очень ощутимо увеличить отзывчивость при нехватке памяти.
Заинтересовавшихся прошу под кат.

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


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

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

Забегая вперед — всё получилось с помощью PyWin32. Правда, неожиданно в процессе пришлось скомпилировать свой пакет для поддержки нужного COM-интерфейса, но обошлось без жертв.

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



Но простой и удобный. Тут надо отметить, что на основной работе я не разработчик, поэтому постоянной среды программирования на рабочем компе не имею и, когда это требуется, пишу на чем придется — bat, JScript, VBA в MSOffice (да, это Windows, корпоративные системы, тут нет bash и perl «из коробки»), макросы в разном ПО и т.д. Все это помогает решить текущую задачу, но уровень и возможности маленько не те, что хотелось бы иметь.

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

Вы скажете, что сейчас есть инструменты на любой вкус и цвет, только выбирай. Лягушка aka TOAD под Oracle, SoapUI для шины и продукты GNU и Apache для всего остального.
Но проблема в том, что все они они специализированы под одну какую-то деятельность, а с другой стороны слишком универсальны — можно сделать многое, но многими действиями. А если возможность в продукте отсутствует, то добавить ее нельзя. Либо продукт закрытый, либо нужно разрабатывать/покупать плагин, либо качать исходники и в них разбираться. А мне нужен был инструмент, в котором простые действия делаются просто, а на сложные сначала тратится немного времени и дальше опять все просто.

Ингредиенты перечисляются по понижению массовой доли: что ближе к началу, того больше по массе. Вещества, которых в составе менее 1% считаются равнозначными для этого списка, и их можно указывать после основных в любом порядке. В РФ по закону указывается всё без исключения (нет ситуации, когда при малом содержании можно пропускать вещество), и на практике это соблюдается. Почему — чуть ниже.

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

Всем привет! В своей прошлой статье я писал об организации модульной системы мониторинга для микросервисной архитектуры. Ничего не стоит на месте, наш проект постоянно растёт, и количество хранимых метрик — тоже. Как мы организовали переход с Graphite+Whisper на Graphite+ClickHouse в условиях высоких нагрузок, об ожиданиях от него и результатах миграции читайте под катом.

У меня дома используется Debian Sid. Большей частью он весьма и весьма хорош, но местами он слишком Bleeding слишком Edge. Например, когда отгружает пакеты, ломающие работоспособность системы. Вчера приехал wpasupplicant, который сломал мне wifi. Я его откатил, но в процессе я подумал, что многие пользователи не умеют этого делать. Рассказ "как откатить плохой apt-get install/upgrade" — в этом посте.

Ситуация

Мы сделали apt-get install что-то, или apt-get upgrade, или даже apt-get dist-upgrade, и после перезагрузки (или даже сразу же) обнаружили, что так нельзя. Сервис не стартует, убрана важная нам фича, кто-то падает и т.д. Мы хотим откатиться. Но вот, незадача — куда именно мы не знаем, потому что какая была версия до обновления мы не знаем.

Все мы любим --help и man. Несмотря на появление многочисленных форумов, Stack Exchange и прочих ресурсов, хорошим тоном в начале решения своих проблем по-прежнему остаётся самостоятельный поиск ответа в официальной документации (и на этих ресурсах вам скорее всего об этом сразу напомнят). Однако лень продолжает двигать прогресс даже там, где не всегда того ожидаешь. Впрочем, это не только лень — бывают и другие аргументы в пользу «упрощений»…

В общем, оказалось, что классический man устраивает не всех. Поэтому появился проект tldr, который, следуя своей расшифровке «Too long; didn't read», решил принести в консоль лаконичную документацию, содержащую только самое главное. Проекту tldr уже больше 3 лет, но про него ещё почему-то не писали на хабре.

В этой статье представлены три небольшие истории, которые произошли в нашей практике: в разное время и в разных проектах. Объединяет их то, что они связаны с сетевой подсистемой Linux (Reverse Path Filter, TIME_WAIT, multicast) и иллюстрируют, как глубоко зачастую приходится анализировать инцидент, с которым сталкиваешься впервые, чтобы решить возникшую проблему… и, конечно, какую радость можно испытать в результате полученного решения.