По задаче реализовать url shortener сервис можно извратиться и написать на Nginx + MongoDB, ещё -33% технологий от вашего способа. Будет мега быстро и надёжно, но очень сложно поддерживать :)
Так пишете, будто PHP + MySQL — это единственный набор инструментов, на котором можно сделать быстро и на коленке. И если человек ответил PHP + MySQL, то можно не спрашивать его что делать если ваш механизм репликации дал сбой или один из серваков накрылся? И не надо спрашивать как можно будет распределить нагрузку между странами?
Может для кого-то быстрее и качественнее будет сделать на NodeJS + MongoDB + AngularJS, а вы сразу его выпендрежником посчитайте и собеседование для него усложнится или станет непроходимым вовсе. А все почему? Потому, что вы ищите PHP разработчика и хотите использовать везде в своих проектах MySQL, но в вакансии нигде не написали об этом? А может ваш кандидат плохо знает эти инструменты, но в совершенстве овладел стеком RoR + PostgreSQL?
И почему вы считаете, что MySQL прост? Наверняка есть люди, которые никогда с ним не работали и для них простым будет тот инструмент, с которым они всю жизнь работали, возможно это будет даже Oracle или Firebird. Они, на ваш взгляд, сложнее или проще чем MySQL?
Модный инструмент — это не всегда только модный инструмент, который люди используют только ради того, чтобы использовать.
Я бы, например, использовал для упомянутой вами выше задачи именно MongoDB в качестве СУБД, т.к. довольно хорошо знаю как с ней работать и она умеет реплицироваться и шардиться из коробки (чем не может похвастаться MySQL). Если реплика сдохнет, то это вообще не проблема. А для надежного шардинга можно использовать схему с shard + replica set. Если сдохнет реплика в шарде, то это опять же не проблема, а вероятность выхода из строя целого шарда, например, с тремя репликами — уже маловероятна.
Какое-то предвзятое у вас отношение к тем кто умеет или хотя бы знает, что можно использовать какой-то не стандартный на ваш взгляд (PHP + MySQL) набор инструментов, который по мнению кандидата будет подходить лучше для решения этой задачи. Не всегда же кандидаты глупее вас. Тем более, что это тестовое задание же, в реальности человек придет в проект с уже подобранным стеком технологий и будет решать задачи на нем (если вы, конечно, не ищите первого человека в проект, который еще не начат).
Задача реплицирования данных в MongoDB довольно таки не сложная. Намного сложнее хорошо настроить шардинг, чтобы потом не было больно. Но, как мне кажется, такая же по боли проблема будет и в реляционных СУБД.
Возможно вы опечатались и имели ввиду sharding, а не replica set.
Вот теперь оценка производительности более объективная, я доволен!
Спасибо за конкурс, было интересно :) Жаль, что не удалось занять призовое место, но 5-ое место тоже очень не плохой результат :)
А такая производительности у меня потому, что в моём решении есть несколько стратегий сравнения и если во входных данных у правил не было вариантов с вопросительным знаком и только с одной звёздочкой, то работала одна из самых быстрых в моём решении стратегия сравнения, без использования регулярных выражений.
А можно где-нибудь достать именно тот набор данных, который вы использовали при тестировании производительности? Мне чисто из любопытства какие правила были и их сложность посмотреть.
Об этом нюансе не знали организаторы конкурса. Это совсем другой разговор. Если бы организатор знал о таком поведении модуля, то не ставил бы таких условий. И написано было, что в виртуальной машине NodeJS, а не в модуле vm для ноды. Приведённое выше предложение можно трактовать неоднозначно.
Согласен, иначе игра в рулетку получается. И не пришлось бы подгонять тестовые данные под объём на котором у всех скрипт отработает и не свалится. И недовольных было бы меньше. А ещё лучше автоматизировать тестирование и выводить результаты онлайн, чтобы появилось больше мотивации соревноваться, как это было сделано с конкурсом по big data от mailru. Сделал скрипт — загрузил его на их сервак, узнал проходит ли тест на корректность твоё решение, сравнил свой результат с другими участниками. Это будет предварительная оценка. А в конце конкурса перед объявлением победителей сделать тоже самое, только ещё раз и с бОльшим количеством итераций и раундов, чтобы результаты были по-объективнее.
В общем, для организаторов теперь есть куча идей по тому как сделать в следующий раз всё удобнее.
Интересный подход.
В моём бенчмарке с исходными данными от организаторов вы заняли 4-ое место (https://github.com/zbitname/hola_nodejs_challenge). Но при запуске от раза к разу, как выяснилось позже, места немного смещались. Я помню, что ваше решение в некоторых «раундах» на моих тестах было на 2-ом и 3-ом месте, но бывало и ниже.
Тем не менее, получилось очень достойное по производительности решение, несмотря на нестабильность времени выполнения решений ваше держится в первой 10-ке стабильно, чаще даже в первой 5-ке. Хорошо, что вы решили написать об этом статью, т.к. пытаться понять суть того как работает алгоритм по коду у подавляющего большинства участников очень сложно, надо потратить много времени.
организовывать соревнования в разных 'весовых категориях'.
Прошу обратить внимание организаторов на github.com/hola/challenge_mail_filter/pull/5
Добавлены тесты для проверки корректности, такие данные могут ввести пользователи, поэтому их нужно учитывать, следовательно тест на корректность станет более подробным, что может отсеять ещё несколько участников.
В моей версии входные данные идентичные тем, что были в конкурсе, изменён лишь метод тестирования. Я писал об этом уже очень много раз, в описании репозитория об этом написано тоже.
Есть современные, регулярно обновляющиеся инструменты, вроде eslint и jshint.
Может для кого-то быстрее и качественнее будет сделать на NodeJS + MongoDB + AngularJS, а вы сразу его выпендрежником посчитайте и собеседование для него усложнится или станет непроходимым вовсе. А все почему? Потому, что вы ищите PHP разработчика и хотите использовать везде в своих проектах MySQL, но в вакансии нигде не написали об этом? А может ваш кандидат плохо знает эти инструменты, но в совершенстве овладел стеком RoR + PostgreSQL?
И почему вы считаете, что MySQL прост? Наверняка есть люди, которые никогда с ним не работали и для них простым будет тот инструмент, с которым они всю жизнь работали, возможно это будет даже Oracle или Firebird. Они, на ваш взгляд, сложнее или проще чем MySQL?
Модный инструмент — это не всегда только модный инструмент, который люди используют только ради того, чтобы использовать.
Я бы, например, использовал для упомянутой вами выше задачи именно MongoDB в качестве СУБД, т.к. довольно хорошо знаю как с ней работать и она умеет реплицироваться и шардиться из коробки (чем не может похвастаться MySQL). Если реплика сдохнет, то это вообще не проблема. А для надежного шардинга можно использовать схему с shard + replica set. Если сдохнет реплика в шарде, то это опять же не проблема, а вероятность выхода из строя целого шарда, например, с тремя репликами — уже маловероятна.
Какое-то предвзятое у вас отношение к тем кто умеет или хотя бы знает, что можно использовать какой-то не стандартный на ваш взгляд (PHP + MySQL) набор инструментов, который по мнению кандидата будет подходить лучше для решения этой задачи. Не всегда же кандидаты глупее вас. Тем более, что это тестовое задание же, в реальности человек придет в проект с уже подобранным стеком технологий и будет решать задачи на нем (если вы, конечно, не ищите первого человека в проект, который еще не начат).
Возможно вы опечатались и имели ввиду sharding, а не replica set.
Вообще, советую прочитать полностью всё что есть на этом сайте. Благо там не так уж и много всего.
Единственная мысль, которая была подмечена правильно: нужно стараться использовать только module.exports. А в остальном — всё плохо…
Спасибо за конкурс, было интересно :) Жаль, что не удалось занять призовое место, но 5-ое место тоже очень не плохой результат :)
А такая производительности у меня потому, что в моём решении есть несколько стратегий сравнения и если во входных данных у правил не было вариантов с вопросительным знаком и только с одной звёздочкой, то работала одна из самых быстрых в моём решении стратегия сравнения, без использования регулярных выражений.
А можно где-нибудь достать именно тот набор данных, который вы использовали при тестировании производительности? Мне чисто из любопытства какие правила были и их сложность посмотреть.
В общем, для организаторов теперь есть куча идей по тому как сделать в следующий раз всё удобнее.
В моём бенчмарке с исходными данными от организаторов вы заняли 4-ое место (https://github.com/zbitname/hola_nodejs_challenge). Но при запуске от раза к разу, как выяснилось позже, места немного смещались. Я помню, что ваше решение в некоторых «раундах» на моих тестах было на 2-ом и 3-ом месте, но бывало и ниже.
Тем не менее, получилось очень достойное по производительности решение, несмотря на нестабильность времени выполнения решений ваше держится в первой 10-ке стабильно, чаще даже в первой 5-ке. Хорошо, что вы решили написать об этом статью, т.к. пытаться понять суть того как работает алгоритм по коду у подавляющего большинства участников очень сложно, надо потратить много времени.
Вы тут имеете ввиду разный объём входных данных?
Добавлены тесты для проверки корректности, такие данные могут ввести пользователи, поэтому их нужно учитывать, следовательно тест на корректность станет более подробным, что может отсеять ещё несколько участников.