Может кто-то и, правда, пожалуйста, объяснить как можно эмулировать «совершенную копию устройства»?
Я понимаю нечто на ARM эмулировать, но в тексте именно про устройства, там же куча других схем, например, для биометрической идентификации, камере, да даже в аккумуляторе. Внутренняя логика работы может быть не совсем простой, никто ее и схемотехнику не раскрывает. Каждый год выходит новая линейка, как успеть весь зоопарк успевать обновлять.
Пока могу допустить, что имея доступ физический к внутренностям устройства, включая память, можно относительно легко перехватить контроль над системой, а дальше уже заставить ее саму все рассказать.
Да, важно, что НДС можно не платить или же вернуть уже уплаченный по инвойсу (более распространенный вариант). Правда, во втором случае надо будет еще раз скататься, но это часто тоже окупается.
На самом деле не самая лучшая идея. Слово «надежный» может ввести простого пользователя в заблуждение, который подумает, что это еще одна гарантия того, что сайт не мошеннический. Да и сами мошенники могут наличие https, точнее этой надписи, представлять пользователям как доказательство их надежности.
Пользователи должны ясно понимать, что это касается не самого сайта, а только соединения с сайтом.
Имея образование в области автоматизации и управления, забавно было вдруг наткнуться в докладе на своего рода П-регулятор. Вообще много теоретических работ по поводу распределения нагрузки в многоагентной системе. Тем кто занимается такими проблемами стоит на них обратить внимание.
Вариант с покупкой лицензии на один компьютер, конечно, огорчает. Рассмотрите вариант семейной лицензии, а то не напасешься их, когда дома несколько маков. Учитывая, что кроме сторонних разработчиков, сам apple тут и там семейный доступ вводит. Как курс вырос, себе и жене покупать каждый год накладно стало, мягко говоря, учитывая, что надобность все же эпизодическая.
Я недавно решил все-таки воспользоваться благами цивилизации и провести статический анализ кода. Раньше слышал про cppcat, полез на сайт и нашел только то, что он уже давно как закрыт. Так я и не понял, если я индивидуальный разработчик и проект у меня для себя, никакого статического анализа мне не полагается?
И еще, конечно, не понять мне видимо никогда, почему по кнопке купить на самом деле купить ничего нельзя.
Для внутрених переговоров можно использовать интеграцию с hangouts, для внешних если платный аккаунт. Если бесплатный, то вообще можно просто тот же самый hangouts использовать, создавая вручную комнату, ну или то, что есть у клиента, собственно как и в случае sococo.
Так, что в реальности, проблемы нет.
Из статьи вынес для себя, что все же отличие в философии пространства и других таких вещей, но пока непонятна их значимость.
Согласен с другими хабраюзерами, что ваше утверждение требует некой аргументации. Вы же пишите, что он не просто лучше vuejs, а вообще самый лучший для быстрой разработки больших приложений. Поэтому, было бы, конечно, очень интересно узнать подробнее. Я просто не встречал столь категоричных утверждений в обзорах и сравнениях, кроме того "быстро" и "большие приложения" вообще редко рассматриваются, все чаще искуственные мелкие примеры.
Насчет split не уверен, на моей машине разницы почти нет: v1 Ваша версия, v2 Ваша версия, где я просто убрал .split('') в коде. Запускал по три раза, получил следующие очки
v2 2472 / 2450 / 2534
v1 2510 / 2448 / 2486
Node v5.0.0
Вставил в ваш код вместо parse_rule свой код составления регекспа (v3), получил
v3 1242 / 1252 / 1328
(тесты на корректность тоже прогнал)
Мой код c классификацией показывает 1763 / 1791 / 1749, простая проверка всех правил подряд + мемоизация 1028 / 1001 / 1052. Как видно, на тестовых данных оказалось лучше ничего не делать лишнего=).
Так как в репозитории опубликован лишь генератор, а данные тестовые у меня свои на его основе получились, для общей картины прогнал несколько других решений:
Andrew Kashta 600-700
Denis Bezrukov 600-700
Sergey Golub 670-720
Denis Kreshikhin 750-850
Pavel Gruba 975-995
Nadav Ivgi ~1650
Спасибо организатором за конкурс, было очень интересно поучаствовать! Правда, в итоге выслал решение в котором был require модуля маски (забыл вставить внутрь скрипта, при тестировании разных вариантов так было удобнее), а потом еще оказалось, что маски должны быть регистрозависимы, в общем, участвую вне конкурса=)
Идее, что если мы проверяем одни правила и они подходят, то другие проверять совсем не обязательно пришла достаточно быстро. Первоначально планировал строить дерево, смотрю подходят ли маски друг к другу, возможны варианты, что одна как бы более общая, будет родителем, вторая частная дочерним элементом, если они обе подходят друг к другу или не подходят, то будут на одном уровне. В итоге в узлах стоят маски, если она подходит, то смотрим подходят ли дочерние и т.д. Другое дело, что в общем случае дерево получалось слишком плоское, так что какого-то толка от него ждать не приходилось, и на нем приходилось делать слишком много сравнений масок между собой. На сотне правил надо будет посмотреть, может не все так плохо.
Далее была идея строить дерево по символам масок, например, узел 'a', в нем маски начинающиеся на 'а', в его дочернем узле 'b' будут соответственно те, что начинаются на 'ab' и т.д. Вопросительный знак тоже мог быть узлом, в который мы просто всегда входим, а вот звездочка это головная боль, после неё была идея менять порядок на обратный и смотреть символы с конца строки снова до звездочки. Берем емейл и идем по его символам выбирая из дерева подходящие правила.
Упрощенная версия этой идеи это просто классифицировать по первому символу. Берем емейл и проверяем правила на этот символ, еще все начинающиеся на '*' и '?'. Маски делятся на те, где проверяется только from, где только to и оба. Если брать первый и последний символ, то вариантов проверки различных наборов правил уже набегало 81. Производительность в итоге упала, и с полным деревом решено было не заморачиваться.
Далее приправил мемоизацией результата для правила целиком и проверки правил без специальных символов простым сравнением строк. Мемозиация результата для каждого правила показала себя не очень хорошо, так как требуется слишком много памяти и все эти накладные расходы по проверке наличия результата делают результат еще хуже.
Замена регулярок на свою функцию, в общем случае, себя не оправдала, хождение по строке достаточно медленное в js. В си чтобы сравнить строки, ты идешь просто по символам и сравниваешь, в js можно сравнить их целиком, а можно самому по символьно, и тут второй вариант уже медленней. Аналогично, регекспы обрабатывали строку быстрее, чем своя функция проверки паттерна. Наверное, если как в опубликованных тестовых данных, вопросительного знака не будет, а звездочка только в конце или начале это может быть быстрее.
Проблема, которую мне так и не удалось решить это как мне отсортировать результаты действия правил. Дело в том, что все эти деревья и классификации возвращают в итоге возможно подходящие правила в произвольном порядке, а надо чтобы действия применялись в порядке следования правил. Очевидное решение сортировка работает недостаточно быстро, быстрее оказалось сохранять action походящего правила в хеш-таблицу, где ключом будет индекс правила, а значением value. Далее получить все ключи, они будут в порядке возрастания, что нам и надо, пройтись по ним и составить массив. Другое дело, что это какой-то костыль, который съедает 10-15% времени. Может сообщество знает как это можно было бы решить?
Подскажите, пожалуйста, а как будет происходить тестирование производительности? В том плане, что допустим берете набор данных и прогоняете N раз, а в зачет идет среднее или лучшее? Может вы посчитаете среднее, но как-то учтете стандартное отклонение. Или может вы возьмете M наборов данных самых разных, для каждого из них составите рейтинговую таблицу, а потом уже по сумме мест?
Мне почему-то показалось, что автор комментария совсем не имела ввиду именно приведенные по ссылке коаны на руби, а подразумевала аналогичные приведенным по ссылке обучающие, скажем так, инструкции-уроки в соответствующей форме для постижения unix-way.
Наткнулся на итоги вашего прошлого конкурса. Скажите, пожалуйста, а начисление баллов в этот раз будет только на основании затраченного времени или и в этот раз будут разнообразные критерии для начисления дополнительных баллов, которые, вы, возможно, предпочитаете пока держать в секрете?
Может кто-то и, правда, пожалуйста, объяснить как можно эмулировать «совершенную копию устройства»?
Я понимаю нечто на ARM эмулировать, но в тексте именно про устройства, там же куча других схем, например, для биометрической идентификации, камере, да даже в аккумуляторе. Внутренняя логика работы может быть не совсем простой, никто ее и схемотехнику не раскрывает. Каждый год выходит новая линейка, как успеть весь зоопарк успевать обновлять.
Пока могу допустить, что имея доступ физический к внутренностям устройства, включая память, можно относительно легко перехватить контроль над системой, а дальше уже заставить ее саму все рассказать.
Пользователи должны ясно понимать, что это касается не самого сайта, а только соединения с сайтом.
И еще, конечно, не понять мне видимо никогда, почему по кнопке купить на самом деле купить ничего нельзя.
Так, что в реальности, проблемы нет.
Из статьи вынес для себя, что все же отличие в философии пространства и других таких вещей, но пока непонятна их значимость.
v2 2472 / 2450 / 2534
v1 2510 / 2448 / 2486
Node v5.0.0
Вставил в ваш код вместо parse_rule свой код составления регекспа (v3), получил
v3 1242 / 1252 / 1328
(тесты на корректность тоже прогнал)
Мой код c классификацией показывает 1763 / 1791 / 1749, простая проверка всех правил подряд + мемоизация 1028 / 1001 / 1052. Как видно, на тестовых данных оказалось лучше ничего не делать лишнего=).
Так как в репозитории опубликован лишь генератор, а данные тестовые у меня свои на его основе получились, для общей картины прогнал несколько других решений:
Andrew Kashta 600-700
Denis Bezrukov 600-700
Sergey Golub 670-720
Denis Kreshikhin 750-850
Pavel Gruba 975-995
Nadav Ivgi ~1650
Идее, что если мы проверяем одни правила и они подходят, то другие проверять совсем не обязательно пришла достаточно быстро. Первоначально планировал строить дерево, смотрю подходят ли маски друг к другу, возможны варианты, что одна как бы более общая, будет родителем, вторая частная дочерним элементом, если они обе подходят друг к другу или не подходят, то будут на одном уровне. В итоге в узлах стоят маски, если она подходит, то смотрим подходят ли дочерние и т.д. Другое дело, что в общем случае дерево получалось слишком плоское, так что какого-то толка от него ждать не приходилось, и на нем приходилось делать слишком много сравнений масок между собой. На сотне правил надо будет посмотреть, может не все так плохо.
Далее была идея строить дерево по символам масок, например, узел 'a', в нем маски начинающиеся на 'а', в его дочернем узле 'b' будут соответственно те, что начинаются на 'ab' и т.д. Вопросительный знак тоже мог быть узлом, в который мы просто всегда входим, а вот звездочка это головная боль, после неё была идея менять порядок на обратный и смотреть символы с конца строки снова до звездочки. Берем емейл и идем по его символам выбирая из дерева подходящие правила.
Упрощенная версия этой идеи это просто классифицировать по первому символу. Берем емейл и проверяем правила на этот символ, еще все начинающиеся на '*' и '?'. Маски делятся на те, где проверяется только from, где только to и оба. Если брать первый и последний символ, то вариантов проверки различных наборов правил уже набегало 81. Производительность в итоге упала, и с полным деревом решено было не заморачиваться.
Далее приправил мемоизацией результата для правила целиком и проверки правил без специальных символов простым сравнением строк. Мемозиация результата для каждого правила показала себя не очень хорошо, так как требуется слишком много памяти и все эти накладные расходы по проверке наличия результата делают результат еще хуже.
Замена регулярок на свою функцию, в общем случае, себя не оправдала, хождение по строке достаточно медленное в js. В си чтобы сравнить строки, ты идешь просто по символам и сравниваешь, в js можно сравнить их целиком, а можно самому по символьно, и тут второй вариант уже медленней. Аналогично, регекспы обрабатывали строку быстрее, чем своя функция проверки паттерна. Наверное, если как в опубликованных тестовых данных, вопросительного знака не будет, а звездочка только в конце или начале это может быть быстрее.
Проблема, которую мне так и не удалось решить это как мне отсортировать результаты действия правил. Дело в том, что все эти деревья и классификации возвращают в итоге возможно подходящие правила в произвольном порядке, а надо чтобы действия применялись в порядке следования правил. Очевидное решение сортировка работает недостаточно быстро, быстрее оказалось сохранять action походящего правила в хеш-таблицу, где ключом будет индекс правила, а значением value. Далее получить все ключи, они будут в порядке возрастания, что нам и надо, пройтись по ним и составить массив. Другое дело, что это какой-то костыль, который съедает 10-15% времени. Может сообщество знает как это можно было бы решить?