На самом деле не самая лучшая идея. Слово «надежный» может ввести простого пользователя в заблуждение, который подумает, что это еще одна гарантия того, что сайт не мошеннический. Да и сами мошенники могут наличие 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.
Наткнулся на итоги вашего прошлого конкурса. Скажите, пожалуйста, а начисление баллов в этот раз будет только на основании затраченного времени или и в этот раз будут разнообразные критерии для начисления дополнительных баллов, которые, вы, возможно, предпочитаете пока держать в секрете?
Сейчас у вас в тихих классах размеров и тем, куча копипасты про шрифт, танзишен и т.д., если понадобиться менять, вы предлагаете менять те же настройки транзишена в пяти местах, а если цветов еще больше, то в еще большем количестве. Зачем код так жестоко дублировать то?
Если он везде пристуствует его можно вынести в отдельный тихий класс %btn-default и extend делать либо в нужных классах кнопок, либо в сами тихие классы им расширить. Хотя, конечно, стоило просто завести класс btn c свойствами по-умолчанию, не стоит слишком увлекаться extend'ами.
Ваше решение должно состоять из единственного файла на JS.
Нельзя загружать никаких модулей, даже тех, что входят в стандартный комплект Node.js.
Так то, если вставить код нужных модулей и библиотек в свой файл, кроме нативных естественно, условия формально выполнятся. Уж, чтобы уж совсем было не подкопаться, то лицензии по использованию это разрешают допустим. Можете как-то более развенуто свою позицию описать, пожалуйста.
2. Можете все-таки как-то определить ограничение по памяти. В погоне за быстродействием понятно, что будет увеличиваться расход памяти, так что коль скоро она ограничена, её количество достаточно важно, особенно в рамках разговоров, что «писем будет много».
Допустим 8/16/etc Гб, чтобы можно было протестировать как-то самим, а то ограничений по памяти нет в теории, а на практике у вас будет какое-то вполне конкретное.
By default, --max_old_space_size (which controls the upper limit of the V8 heap) is ~1.5GB.
Вы будете этот лимит менять? В предыдущих версиях ноды, притом, он менялся не до бесконечности, в новой вроде починили.
3. В связи с предыдущим вопросом опять же, не могли бы вы как-то очертить, хотя бы порядок количества сообщений и фильтров. Например, 10K или даже 100K фильтров одно, 10M уже совсем другое, а если больше, то, вообще, надо думать. Память будет как-то ограничена, надо как-то представлять сколько вообще места у нас, может там места на эти самые письма и фильтры только и есть=).
4. Просто на всякий случай, точно ли ваши тесты на корректность будут проверять, что actions у сообщений перечислены «в порядке перечисления правил в массиве rules»? У вас это упоминается, но просто, может они все-таки коммутативны=)
На олимпиадах по программированию типа ACM тесты тоже не дают.
Да, но результат проверки на этих самых тестах виден сразу, хоть сами тесты и не известны, а не в самом конце, когда уже ничего не исправишь. Так то скрывать тесты и проверку провести в самом конце все же не самая лучшая затея по отношению к участникам. Ждать часа X и обнаружить, что в погоне за быстродействием, ты в скрипте не учел какой-то странный случай, не очень хочется.
P.S.
Конкурс отличный, жалею что предыдущие ваши пропустил, отличная разрядка.
Пользователи должны ясно понимать, что это касается не самого сайта, а только соединения с сайтом.
И еще, конечно, не понять мне видимо никогда, почему по кнопке купить на самом деле купить ничего нельзя.
Так, что в реальности, проблемы нет.
Из статьи вынес для себя, что все же отличие в философии пространства и других таких вещей, но пока непонятна их значимость.
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% времени. Может сообщество знает как это можно было бы решить?
Если он везде пристуствует его можно вынести в отдельный тихий класс %btn-default и extend делать либо в нужных классах кнопок, либо в сами тихие классы им расширить. Хотя, конечно, стоило просто завести класс btn c свойствами по-умолчанию, не стоит слишком увлекаться extend'ами.
1. Использование стороннего кода
Так то, если вставить код нужных модулей и библиотек в свой файл, кроме нативных естественно, условия формально выполнятся. Уж, чтобы уж совсем было не подкопаться, то лицензии по использованию это разрешают допустим. Можете как-то более развенуто свою позицию описать, пожалуйста.
2. Можете все-таки как-то определить ограничение по памяти. В погоне за быстродействием понятно, что будет увеличиваться расход памяти, так что коль скоро она ограничена, её количество достаточно важно, особенно в рамках разговоров, что «писем будет много».
Допустим 8/16/etc Гб, чтобы можно было протестировать как-то самим, а то ограничений по памяти нет в теории, а на практике у вас будет какое-то вполне конкретное.
Кроме того у самой ноды, если верить github.com/nodejs/node/wiki/Frequently-Asked-Questions на процесс оно есть
Вы будете этот лимит менять? В предыдущих версиях ноды, притом, он менялся не до бесконечности, в новой вроде починили.
3. В связи с предыдущим вопросом опять же, не могли бы вы как-то очертить, хотя бы порядок количества сообщений и фильтров. Например, 10K или даже 100K фильтров одно, 10M уже совсем другое, а если больше, то, вообще, надо думать. Память будет как-то ограничена, надо как-то представлять сколько вообще места у нас, может там места на эти самые письма и фильтры только и есть=).
4. Просто на всякий случай, точно ли ваши тесты на корректность будут проверять, что actions у сообщений перечислены «в порядке перечисления правил в массиве rules»? У вас это упоминается, но просто, может они все-таки коммутативны=)
Да, но результат проверки на этих самых тестах виден сразу, хоть сами тесты и не известны, а не в самом конце, когда уже ничего не исправишь. Так то скрывать тесты и проверку провести в самом конце все же не самая лучшая затея по отношению к участникам. Ждать часа X и обнаружить, что в погоне за быстродействием, ты в скрипте не учел какой-то странный случай, не очень хочется.
P.S.
Конкурс отличный, жалею что предыдущие ваши пропустил, отличная разрядка.