Наверное, мои вопросы будут скорее к оригиналу, нежели к Вашему переводу. Но всё же.
Отсутствует полный исходный код примеров. В частности, что в оригинале, что в переводе отсутствует код метода PassTheTime.
Асинхронность в .net, к большому сожалению не настолько проста, как описывается в статье =(( Наверное, стоило бы в заключение дать ссылки либо на другие примеры использования, либо на более глубоко разбираемые примеры по async-await.
В приведенном примере синхронного кода если, например, внутри метода BakeCake() вывалится Exception — это прервет выполнение всех последующих методов.
public static async Task<bool> BakeCakeAsync(bool isPreheated)
{
if (!isPreheated)
throw new InvalidOperationException("before 1st await");
var result = await InnerBakeCakeAsync(isPreheated).ConfigureAwait(false);
if (isPreheated)
throw new InvalidOperationException("after await");
return result;
}
Так вот: если метод вызовется isPreheated = true, то исключение в основном методе "поймается" на строке
Большое спасибо за перевод! Чисто из любопытства: почему не сдали делать 1 туториал=1 статья?
Отмечу, что вы вводите терминологию пакет -> кадр ("до декодирования" -> "после декодирования"). Однако в нескольких местах для обозначения кадра вы используете слово "фрейм" (т.е. без перевода).
Также вы, кажется, пропустили в первом туториале сноску
Тут фишка в том, что для удобства (в том числе и, наверное, чтения кода), в свежем ffmpeg-е функцию avcodec_decode_video2 даже заменили на пару функций:
И по тогда получается легче обработать случаи, когда мы:
а) должны ffmpeg-у передать несколько пакетов прежде, чем получим хотя бы один кадр (это вроде раз история с "частичными пакетами" из ссылки)
б) на один пакет нам возвращают несколько кадров. Кстати подскажите, а вообще возможно ли такое? На ум почему-то приходит только случай, когда мы декодируем видеопоток с камеры, которая "видит" статичную картинку.
И подчеркну: я не уотверждаю, что практика — это плохо.
Просто по-моему важно соблюдать баланс между знанием теории и практическим опытом. А ругать только теорию или только практику (или ещё лучше конкретных представителей, вледующих только одним из вышеуказанного) — это как ругаться что один совок что пыль не убирает, при этом зная, что совок используют в паре со шваброй.
Да, я мог посещать курсы по этим предметам. Но гораздо больше можно узнать, если самому создавать вещи, делать ошибки и по-настоящему «чувствовать» всё это, а не узнавать из книги или лекции.
Видимо, вам просто не везло с книгами и/или с лекторами. Была ж даже статья на хабре по полезным книгам для программиста (не могу сейчас, правда, найти, подмогите, товарищи!).
Не то чтобы они не знают свой предмет, просто главное в преподавании — это исследовать предмет и понимать теорию, а не писать код и приносить пользу клиенту.
Дональд Кнут исследует предмет и очень хорошо понимает теорию — и вы утверждаете, что его работа не приносит клиенту пользы?) По мне как очень даже приносит: люди, разбирающиеся в алгоритмах, могут написать более эффективный код и за меньшее время. И как по мне, это очень даже польза клиенту путсь и косвенная).
Уверен, шаблоны разработки ПО (я про работу GoF), приносят не меньше пользы.
И курсы с реальной практической пользой имеются. И лекторы с опытом — тоже (от меня один пример: Д.Ю. Ватолин и его курс "Алгоритмы сжатия данных", который по сути является отборочным для попадания в лабораторию компьютерной графики ВМК МГУ).
Иначе вы можете нарваться на то, что в процессе разработки будете изобретать колесо или велосипед. Причём не факт что качественные...
Данная уязвимость была обнаружена 26 февраля 2017 года и исправлена 28 февраля 2017 года.
Снимаю шляпу не только перед исследователем, но и перед сотрудниками компании: в кой-то веки серьёзная уязвимость была достаточно оперативно исправлена крупной компанией и не пришлось с месяц стучаться и по десять раз объяснять что это баг а не фича.
Что самое забавное: исходные данные проекта, в котором я участвую сейчас, почти те же. Похожий контракт, плюс похожее ТЗ с прописанными сроками сдачи этапов и фиксированной стоимостью.
НО:
В этот раз в команде семеро, из них 5 разработчиков (и лишь один уровня middle и с опытом менее 2-лет enterprise-разработки).
В договоре заложены сроки с учётом возможных рисков, ибо сразу прописано: для части пунктов ТЗ будет проводиться дополнительное исследование, по результатам которого и будет понятно как сделать лучше. И время на исследование тоже выделено соответственно.
В команде есть адекватный аналитик, который согласовывает с нами позицию «что и как мы в результате делаем» перед поездкой к заказчику.
В команде есть Project Owner, который ездит с аналитиком к заказчику и в курсе всего, что требует от нас заказчик, и который также общается с разработчиками и в курсе того, с какими проблемами они сталкиваются.
Компоненты системы изначально создаются вместе с тестами (конечно это не TDD, но мы стараемся). Мы все знаем и одинаково понимаем gitflow (обычный, не rebase). Имеется ограниченный code-review и включена поддержка merge-request’ов (gitlab). И, разумеется, сервер Teamcity помимо Continuous Build-а, гоняет созданные тесты перед мерджем в dev (сейчас, правда, при каждом коммите, а не перед мерджем, но мы работаем чтобы это поправить).
В самом начале этапа разработки было потрачено время на «платформу»: сделали базовые сервисы для работы с БД, с окнами и вкладками (UI), и прочим (т.е. Infrastructural Service) – чтобы даже вновь пришедший junior в течение недели мог понять, как создать вкладку (не разбираясь в Prism), как вызвать хранимку с параметрами из БД и получить в ответ коллекцию объектов (опять же, даже ничего не зная про Dapper), и т.д.
Так что надежда, что мы выполним задачу в срок, достаточно сильна, чего и желаю всем хабрачитателям.
Читаю комментарии и вспоминаю свою первую контору, в которой я официально начал работать по специальности (то есть разработчиком).
Начнём с того, что де-факто технический директор (далее ТД) Компании считала себя Project-менеджером данного проекта, а по факту была дочкой гендира компании-Заказчика со всеми вытекающими требованиями.
Все разработчики исключая меня (то есть ещё 2 человека) были либо недавно выпустившимися студентами, либо ещё студентами и работали на полставки. И ни у кого из нас за плечами не было опыта промышленной разработки – при этом и наниматель, и ТД об этом знали, но удивлялись, почему же мы тормозим и почему у нас накапливаются задачи.
Как следствие, ТД (как «единственный адекватный человек») решила ввести некое подобие code-review, на котором нам говорили, как надо было делать (то есть ввели проектирование кода после его написания). Причём по многим концептуальным вопросам ТД отправляла нас в Гугл («и вы ещё спрашиваете, что такое паттерн «репозиторий»?). Уже много позже я понял, что сама ТД скорее всего обучалась применению паттернов проектирования там же, куда посылала нас.
Через 4 месяца после моего прихода по настоянию ТД (ибо «как-то медленно двигаемся») к проекту подключили аналитика, который в течение пары недель расписал ТЗ на пару месяцев вперёд (согласно вашей классификации – чёткое ТЗ со сроками = водопад).
До этого ТЗ составляла лично ТД через обсуждение, иногда описывая требования через Ж…. иру.
Если мы выполняли какую-то задачу не так, как хотела ТД или в коде были баги, мы наш код переписывали. После первой пары FAIL-ов время на переписывание нам перестали давать. А задачи надо было делать и сдавать по плану в рамках Контракта – в общем, от Заказчика начало доставаться и аналитику.
И самое вкусное – ТД была на 100% уверена и всем говорила, что у нас чётко отлаженный SCRUM с недельными спринтами через Ж…иру. При этом в самой Jira для скрама использовались KANBAN-доски; длина спринта менялсь в зависимости от частоты поездок ТД и анализика к Заказчику — а они в конце туда ездили каждые 3-4 дня.
Итог: 1 ушёл сам (по иронии судьбы за время этой работы он много раз прочитал Scrum Guide и на следующем месте научился его правильно понимать и применять), 1 уволили за профнепригодность (это был я). Третий на тот момент остался, что с ним стало далее не в курсе.
А компания, говорят, продолжает активно развиваться…
Пример серьезного софта, меняющего свое поведение при установке его на ВМ = Windows. Фишка в том, что в MS требуют отдельную лицензию на каждую ВМ (одной на всю физическую машину им мало). Предположу, что именно поэтому на ВМ при клонировании может слететь активация.
Думаю, не следует в рамках заметки смешивать задачу определения запуска в окружении ВМ и обфускацию кода.
А насчёт спуска до уровня машинных кодов — не вижу причин не спускаться если это даст дополнительные данные. До инструкции CPUID мы уже спустились (через вызов unmanaged C++ библиотеки, заметка на хабр в процессе).
> поиск и пользование уязвимостей и бэкдоров самих ВМ.
В теории — да. Но на практике для обеспечения приемлемой производительности гипервизор вынужден использовать аппаратные возможности виртуализации (типа Intel VT-x). И, завязавшись на особенности их использования, можно ещё больше увеличить вероятность определения ВМ.
Во-первых огромное спасибо за ссылку — одна из целей публикации это сбор дополнительной информации касательно особенностей детектирования ВМ.
А насчёт бесполезности — мне кажется вы рано клеймите этим словом последующие уровни. У первого уровня задача по сути обозначить проблему. На втором уровне добавляется детектирования через инструкцию CPUID (EAX=40000000h) и через бит hypervisor present (EAX = 1, смотрим 31-бит в ECX). Это поведение гипервизоров пропатчить чуть сложнее.
А на 3м уровне рассматриваются уже особенности реализации некоторых гипервизоров для определения.
Приведу конкретный пример: применительно к тому же VMWare — в ВМ чипсет компьютера детектируется как Intel 440BX (это socket 370, уровень Pentium II). Соответственно, увидев в системе указаный чипсет вкупе с процессором Intel Kaby Lake, да ещё и одноядерным — мы можем почти со 100% уверенностью утверждать что это виртуалка.
mayorovp, прошу прощения, я привёл неверный пример. lair в комментарии ниже привел правильный.
Наверное, мои вопросы будут скорее к оригиналу, нежели к Вашему переводу. Но всё же.
Отсутствует полный исходный код примеров. В частности, что в оригинале, что в переводе отсутствует код метода PassTheTime.
Асинхронность в .net, к большому сожалению не настолько проста, как описывается в статье =(( Наверное, стоило бы в заключение дать ссылки либо на другие примеры использования, либо на более глубоко разбираемые примеры по async-await.
В приведенном примере синхронного кода если, например, внутри метода BakeCake() вывалится Exception — это прервет выполнение всех последующих методов.
А вот для асинхронного кода уже начинаются вариации. Похожий пример описан в блоге Stephen Cleary: https://blog.stephencleary.com/2016/12/eliding-async-await.html (раздел Exceptions).
Поясню на примере.
Пусть код метода BakeCakeAsync выглядит так:
Так вот: если метод вызовется isPreheated = true, то исключение в основном методе "поймается" на строке
И AddFrostingIngredients не будет вызван.
А вот если вызвать BakeCakeAsync вызовется с isPreheated = false, то исключение "поймается" уже только на строке с await-ом:
И получается, что AddFrostingIngredients вполне себе успеет выполниться
То есть при определенных условиях мы подготовим замороженные ингредиенты к приготовлению не посмотрев даже, что с процессом выпекания что-то не так.
Большое спасибо за перевод! Чисто из любопытства: почему не сдали делать 1 туториал=1 статья?
Отмечу, что вы вводите терминологию пакет -> кадр ("до декодирования" -> "после декодирования"). Однако в нескольких местах для обозначения кадра вы используете слово "фрейм" (т.е. без перевода).
Также вы, кажется, пропустили в первом туториале сноску
Тут фишка в том, что для удобства (в том числе и, наверное, чтения кода), в свежем ffmpeg-е функцию avcodec_decode_video2 даже заменили на пару функций:
И по тогда получается легче обработать случаи, когда мы:
а) должны ffmpeg-у передать несколько пакетов прежде, чем получим хотя бы один кадр (это вроде раз история с "частичными пакетами" из ссылки)
б) на один пакет нам возвращают несколько кадров. Кстати подскажите, а вообще возможно ли такое? На ум почему-то приходит только случай, когда мы декодируем видеопоток с камеры, которая "видит" статичную картинку.
И подчеркну: я не уотверждаю, что практика — это плохо.
Просто по-моему важно соблюдать баланс между знанием теории и практическим опытом. А ругать только теорию или только практику (или ещё лучше конкретных представителей, вледующих только одним из вышеуказанного) — это как ругаться что один совок что пыль не убирает, при этом зная, что совок используют в паре со шваброй.
Видимо, вам просто не везло с книгами и/или с лекторами. Была ж даже статья на хабре по полезным книгам для программиста (не могу сейчас, правда, найти, подмогите, товарищи!).
Дональд Кнут исследует предмет и очень хорошо понимает теорию — и вы утверждаете, что его работа не приносит клиенту пользы?) По мне как очень даже приносит: люди, разбирающиеся в алгоритмах, могут написать более эффективный код и за меньшее время. И как по мне, это очень даже польза клиенту путсь и косвенная).
Уверен, шаблоны разработки ПО (я про работу GoF), приносят не меньше пользы.
И курсы с реальной практической пользой имеются. И лекторы с опытом — тоже (от меня один пример: Д.Ю. Ватолин и его курс "Алгоритмы сжатия данных", который по сути является отборочным для попадания в лабораторию компьютерной графики ВМК МГУ).
Иначе вы можете нарваться на то, что в процессе разработки будете изобретать колесо или велосипед. Причём не факт что качественные...
Снимаю шляпу не только перед исследователем, но и перед сотрудниками компании: в кой-то веки серьёзная уязвимость была достаточно оперативно исправлена крупной компанией и не пришлось с месяц стучаться и по десять раз объяснять что это баг а не фича.
Разумеется!
Что самое забавное: исходные данные проекта, в котором я участвую сейчас, почти те же. Похожий контракт, плюс похожее ТЗ с прописанными сроками сдачи этапов и фиксированной стоимостью.
НО:
Так что надежда, что мы выполним задачу в срок, достаточно сильна, чего и желаю всем хабрачитателям.
Читаю комментарии и вспоминаю свою первую контору, в которой я официально начал работать по специальности (то есть разработчиком).
До этого ТЗ составляла лично ТД через обсуждение, иногда описывая требования через Ж…. иру.
И самое вкусное – ТД была на 100% уверена и всем говорила, что у нас чётко отлаженный SCRUM с недельными спринтами через Ж…иру. При этом в самой Jira для скрама использовались KANBAN-доски; длина спринта менялсь в зависимости от частоты поездок ТД и анализика к Заказчику — а они в конце туда ездили каждые 3-4 дня.
Итог: 1 ушёл сам (по иронии судьбы за время этой работы он много раз прочитал Scrum Guide и на следующем месте научился его правильно понимать и применять), 1 уволили за профнепригодность (это был я). Третий на тот момент остался, что с ним стало далее не в курсе.
А компания, говорят, продолжает активно развиваться…
Пример серьезного софта, меняющего свое поведение при установке его на ВМ = Windows. Фишка в том, что в MS требуют отдельную лицензию на каждую ВМ (одной на всю физическую машину им мало). Предположу, что именно поэтому на ВМ при клонировании может слететь активация.
А насчёт спуска до уровня машинных кодов — не вижу причин не спускаться если это даст дополнительные данные. До инструкции CPUID мы уже спустились (через вызов unmanaged C++ библиотеки, заметка на хабр в процессе).
В теории — да. Но на практике для обеспечения приемлемой производительности гипервизор вынужден использовать аппаратные возможности виртуализации (типа Intel VT-x). И, завязавшись на особенности их использования, можно ещё больше увеличить вероятность определения ВМ.
Во-первых огромное спасибо за ссылку — одна из целей публикации это сбор дополнительной информации касательно особенностей детектирования ВМ.
А насчёт бесполезности — мне кажется вы рано клеймите этим словом последующие уровни. У первого уровня задача по сути обозначить проблему. На втором уровне добавляется детектирования через инструкцию CPUID (EAX=40000000h) и через бит hypervisor present (EAX = 1, смотрим 31-бит в ECX). Это поведение гипервизоров пропатчить чуть сложнее.
А на 3м уровне рассматриваются уже особенности реализации некоторых гипервизоров для определения.
Приведу конкретный пример: применительно к тому же VMWare — в ВМ чипсет компьютера детектируется как Intel 440BX (это socket 370, уровень Pentium II). Соответственно, увидев в системе указаный чипсет вкупе с процессором Intel Kaby Lake, да ещё и одноядерным — мы можем почти со 100% уверенностью утверждать что это виртуалка.