Строго говоря в b попадает новая функция (результат вызова .bind(window)), которая при вызове устанавливает в качестве контекста выполнения this предоставленное значение (window) — что и происходит в вашем примере.
Такие ключи обычно делаются в hardware исполнении. То есть, нужно подписать — вставил usb устройство с ключом, подписал, вытащил. С защитой от копирования, чтобы такие ситуации были в принципе невозможны.
Хотите верьте хотите нет, хотел как-то начать пользоваться твиттером — однако мой аккаунт уводили раз за разом. При этом не было никаких писем от Твиттера типа «Вы точно хотите восстановить доступ?», не было ни одной привязки ни к одному устройству, и всё равно методично раз за разом я терял доступ к своему аккаунту. В поддержку пробиться так и не получилось, пришлось просто забить. Так что, честно говоря, я совсем не удивлён. Странно что увод аккаунтов только сейчас получил такую огласку.
Тут уже за меня всё ответили :)
Ни в коем случае не критикую ваш подход, как по мне — главное, чтобы поставленная задача была решена, конкретный способ и терминология — это уже детали.
LR(1) грамматики удобнее в том плане, что с их помощью можно описать большее количество грамматик, чем при помощи LL(1).
И ещё один момент — если вы подаёте на вход произвольные грамматики, рано или поздно на вход попадёт некорректная грамматика. Как решается эта проблема в случае с рекурсивным спуском?
Хм, спасибо, значит буду урезать права.
Можете в двух словах описать механизм повышения привилегий, учитывая что:
1. Запускаемый бинарник лежит в Program Files — т. е. предполагается что с обычными правами его просто так не подменишь
2. Хэндл дублируется для конкретного процесса — т. е. за его пределами не юзабелен.
Пока что открываю процесс со всеми возможными правами (ProcessAccessFlags.All) и использую DuplicateOptions.DuplicateSameAccess — надо полагать access mask будет выглядеть соответствующим образом (что-то вроде 0x001F0FFF). Чем это может быть чревато?
Спасибо, как раз то, что искал!
Вот вам ещё пример. Есть некое приложение, которое должно запускаться от имени администратора по своей природе. Это приложение торчит наружу COM-интерфейсом, т. е. по идее для управления им права администратора не требуются. Однако, для удобства использования и для того, чтобы иметь, например, возможность завершить процесс или сделать с ним ещё что-то полезное, нам нужно иметь его handle.
Таким образом, у нас есть служба, которая запускает процесс (от имени администратора) и дублирует его хэндл через WCF в клиентское приложение, которое уже делает с ним всё, что необходимо, не требуя при этом повышения прав.
Что можете сказать про такой расклад?
LR(1) парсер не пробовали реализовать? Должно помочь с проблемами по типу левой рекурсии. В свое время делал и рекурсивный спуск и LL(1) и LR(1) и LALR(1), как раз в контексте разбора произвольной грамматики, LR(1) показался мне самым эффективным из них. Хотя рекурсивный спуск, конечно, реализуется в разы проще.
Ну я позволю себе с вами не согласиться. Во-первых, по-хорошему, QA и DevOps — это отдельные люди (и даже отделы). Рефакторинг и багфиксинг сводится к тому, чтобы разобраться и написать код. Юнит-тесты — тоже код. Лично я замечаю, что чем дальше — тем меньше времени отнимает именно написание кода.
Во-вторых, код-ревью — это важная часть обязанностей сеньора, и тоже отнимает заметную часть времени. В статье идёт речь о разработке клиентской части приложения, зачастую это отдельный продукт (чтобы писать серверную часть нужны другие навыки, и обычно это тоже делает другая команда), так что да — здесь важно и написать код, и пройти QA (иначе откуда возьмутся баги, которые необходимо пофиксить?), и получить замечания на ревью от коллег и поправить их, и так до тех пор, пока не будет готова версия, которую не стыдно зарелизить (ну или пока не настанет дедлайн :)).
Если вы работаете в аутсорс конторе — то вас также будут всё время дёргать на оценку. Кроме того, кто-то должен собеседовать новых людей в команду, и при всём при этом в рабочем дне всего лишь 8 часов. Так что, если разработка у вас занимает 40% времени — это уже очень хорошо.
Я уже не говорю про то, что кто-то вместо работы играет в теннис и пьёт кофе на кухне :)
Ни в коем случае не критикую ваш подход, как по мне — главное, чтобы поставленная задача была решена, конкретный способ и терминология — это уже детали.
LR(1) грамматики удобнее в том плане, что с их помощью можно описать большее количество грамматик, чем при помощи LL(1).
И ещё один момент — если вы подаёте на вход произвольные грамматики, рано или поздно на вход попадёт некорректная грамматика. Как решается эта проблема в случае с рекурсивным спуском?
Можете в двух словах описать механизм повышения привилегий, учитывая что:
1. Запускаемый бинарник лежит в Program Files — т. е. предполагается что с обычными правами его просто так не подменишь
2. Хэндл дублируется для конкретного процесса — т. е. за его пределами не юзабелен.
Так сказать, врага нужно знать в лицо.
Вот вам ещё пример. Есть некое приложение, которое должно запускаться от имени администратора по своей природе. Это приложение торчит наружу COM-интерфейсом, т. е. по идее для управления им права администратора не требуются. Однако, для удобства использования и для того, чтобы иметь, например, возможность завершить процесс или сделать с ним ещё что-то полезное, нам нужно иметь его handle.
Таким образом, у нас есть служба, которая запускает процесс (от имени администратора) и дублирует его хэндл через WCF в клиентское приложение, которое уже делает с ним всё, что необходимо, не требуя при этом повышения прав.
Что можете сказать про такой расклад?
Во-вторых, код-ревью — это важная часть обязанностей сеньора, и тоже отнимает заметную часть времени. В статье идёт речь о разработке клиентской части приложения, зачастую это отдельный продукт (чтобы писать серверную часть нужны другие навыки, и обычно это тоже делает другая команда), так что да — здесь важно и написать код, и пройти QA (иначе откуда возьмутся баги, которые необходимо пофиксить?), и получить замечания на ревью от коллег и поправить их, и так до тех пор, пока не будет готова версия, которую не стыдно зарелизить (ну или пока не настанет дедлайн :)).
Если вы работаете в аутсорс конторе — то вас также будут всё время дёргать на оценку. Кроме того, кто-то должен собеседовать новых людей в команду, и при всём при этом в рабочем дне всего лишь 8 часов. Так что, если разработка у вас занимает 40% времени — это уже очень хорошо.
Я уже не говорю про то, что кто-то вместо работы играет в теннис и пьёт кофе на кухне :)