Ну использование regenerator в принципе обоснованно только для очень старых платформ, которые не поддерживают генераторы, а там уже о скорости никто не думает — да и нативных промисов там в таком случае тоже отродясь не было, поэтому сравнивать не с чем. Для окружений возрастом хотя бы в пару лет уже имеет смысл использовать исключительно генераторы.
А о том, что генераторы медленнее промисов — у вас есть какие-то материалы по теме? Быстрый гуглеж показал результаты противоположные вашему заявлению, но я их не верифицировал.
Правильно — вы планировали статью "ах, какой я молодец", а получилась статья "как написать говно на JS и не подать виду".
Вы вместо простого и элегантного подхода выбрали самый сложный и неправильный — вместо new Promise((resolve, reject) => { ... }), как рекомендует спецификация, вы используете defer, который мало того, что тянет за собой огромный, медленный Q, еще и стандарту не соответствует.
Нагородили итератор и генератор поверх массива, вместо for (let x of y) { ... }, который нода, между прочим, поддерживает уже очень давно, даже без дополнительных флагов. Сделали мешанину анонимных функций в теле main. Зачем?!.. Зачем там замыкание, вы объясните? На что оно замыкается? Нахрена ему это делать прямо в main при каждом вызове?
Родина вам async/await дала — пиши. Не хочу, хочу setTimeout. И это программисты? Какая может быть уважительная причина их не использовать?
Наверное, пройдет еще лет 40, и люди начнут потихоньку использовать современный Javascript, но не везде и не полностью, ведь все еще нужно поддерживать IE5.5.
Автор, у вас вместо кода дикое, мерзкое, нечитаемое месиво вместо кода.
import Promise from 'bluebird';
async function process(item) {
console.log(`start call for ${item}`);
await Promise.delay(1000);
console.log(`end call for ${item}`);
}
async function main() {
const items = [1, 2, 3, 4, 5];
for (let item of items) {
await process(item);
}
}
main().then(() => {
console.log(`done`);
});
Миль пардон, с номерами моделей вышла накладка, связанная с «Абрам напел по телефону». Еще раз мои извинения.
Модели следующие:
Z2 D6502 (Android 6.0.1, билд 23.5.A.0.575) — нет Стамины. Было два обновления — до 6, и до 6.0.1.
Z3+ D6553 (Android 6.0.1, билд 32.2.A.0.224) — есть Стамина. Похоже, было три обновления — до 6, до 6.0.1, и какой-то еще, который, похоже, и добавлял Стамину. Третий билд не был замечен вовремя, что послужило причиной конфуза.
При обновлении на шестерку обещали вернуть поддержку Ultra Stamina в 6.0.1. Как показала практика, ни на Z3, ни на Z5+ никакой ultra stamina нет, да и обычной стамины тоже нет.
Есть где-то playground с типичным сетапом этого lshell? т.к. не могу отделаться от ощущения, что несмотря на все предосторожности, из песочницы можно вырваться, не прибегая даже к уязвимостям самого lshell, а используя «подручные средства».
Странно, но поиск в тексте страницы по «OTP» и «токен» ничего не дал.
Вместо фиксированного кода, который можно подсмотреть, выбить и т.д., можно использовать TOTP-токены типа этого либо приложения аля Google Authenticator. Для защиты от входа под принуждением можно пропускать заранее известную цифру при чистом вводе — например, пятую цифру шестизначного кода.
По запросу "superdeterminism" и "супердетерминизм" уже немного больше результатов. Возможно, что просто термин переводится не так — как-то типа «супердетерминированные» (хотя тут гугл выдает сорта томатов). Возможно, просто нет материалов в русскоязычной среде?
Честно говоря, я знаю только одну супердетерминистичную теорию — qst. У меня есть книга по этой теории, которую я попробую перевести — чтобы люди, которые умнее меня в данной области, могли как-то это прокомментировать. Но там 585 страниц, так что врядли стоит ожидать всего и сразу в скором времени.
Соглашусь. Вроде только настроился на чтение, объяснение теории, откуда берется лимит Шеннона, какие следствия модели Шеннона и тому подобное — и все, закончилось.
Считаем условно, что емкость этого устроства — 50 десятичных мегабайт, т.е. 400'000'000 бит. Если я ничего не пропустил в принципах работы ферритовых сердечников, то на один бит идет один элемент памяти. А это значит, что один бит будет весить 62.5 мкг, вместе с сердечником и обмоткой. Миниатюрные элементы получаются, однако.
Ну использование regenerator в принципе обоснованно только для очень старых платформ, которые не поддерживают генераторы, а там уже о скорости никто не думает — да и нативных промисов там в таком случае тоже отродясь не было, поэтому сравнивать не с чем. Для окружений возрастом хотя бы в пару лет уже имеет смысл использовать исключительно генераторы.
А о том, что генераторы медленнее промисов — у вас есть какие-то материалы по теме? Быстрый гуглеж показал результаты противоположные вашему заявлению, но я их не верифицировал.
Тема следующего поста — преобразуем нипанятный код с промисами в нормальный код на коллбэках.
А чем способ комментарием выше не устроил?
Импортнул из двух соображений. Первое — готовая реализация
Promise.delay():Второе — Bluebird в несколько раз быстрее нативных промисов, поэтому имеет смысл его использовать даже там, где промисы поддерживаются нативно.
Правильно — вы планировали статью "ах, какой я молодец", а получилась статья "как написать говно на JS и не подать виду".
Вы вместо простого и элегантного подхода выбрали самый сложный и неправильный — вместо new
Promise((resolve, reject) => { ... }), как рекомендует спецификация, вы используете defer, который мало того, что тянет за собой огромный, медленный Q, еще и стандарту не соответствует.Нагородили итератор и генератор поверх массива, вместо
for (let x of y) { ... }, который нода, между прочим, поддерживает уже очень давно, даже без дополнительных флагов. Сделали мешанину анонимных функций в теле main. Зачем?!.. Зачем там замыкание, вы объясните? На что оно замыкается? Нахрена ему это делать прямо в main при каждом вызове?Родина вам async/await дала — пиши. Не хочу, хочу setTimeout. И это программисты? Какая может быть уважительная причина их не использовать?
Автор, у вас вместо кода дикое, мерзкое, нечитаемое месиво вместо кода.
Модели следующие:
Z2 D6502 (Android 6.0.1, билд 23.5.A.0.575) — нет Стамины. Было два обновления — до 6, и до 6.0.1.
Z3+ D6553 (Android 6.0.1, билд 32.2.A.0.224) — есть Стамина. Похоже, было три обновления — до 6, до 6.0.1, и какой-то еще, который, похоже, и добавлял Стамину. Третий билд не был замечен вовремя, что послужило причиной конфуза.
Вместо фиксированного кода, который можно подсмотреть, выбить и т.д., можно использовать TOTP-токены типа этого либо приложения аля Google Authenticator. Для защиты от входа под принуждением можно пропускать заранее известную цифру при чистом вводе — например, пятую цифру шестизначного кода.
Честно говоря, я знаю только одну супердетерминистичную теорию — qst. У меня есть книга по этой теории, которую я попробую перевести — чтобы люди, которые умнее меня в данной области, могли как-то это прокомментировать. Но там 585 страниц, так что врядли стоит ожидать всего и сразу в скором времени.