Мы получили множество замечаний о методике тестирования решений. Ниже наши ответы на эти замечания.
Тесты на корректность неполны
Спасибо двоим участникам конкурса, приславшим дополнения к нашему набору тестов на корректность. Благодаря этим дополнениям нам удалось выявить несколько решений, выдающих неправильные результаты в редких случаях.
Тесты на производительность дают искажённые результаты из-за особенностей методики тестирования
Мы запускали решения участников в «виртуальной машине», реализованной модулем
vm в Node.js, чтобы предотвратить как использование require, так и другие возможные «сюрпризы» и попытки манипулировать тестовой системой. Однако оказалось, что модуль vm вносит серьёзные искажения в результаты тестирования. В частности, при использовании этого вида виртуализации доступ к глобальному пространству имён становится непропорционально медленным. Из-за этого простой перенос вспомогательных функций в тело функции filter может улучшить производительность в несколько раз. Большинство участников тестировали производительность своего кода простыми обёртками с использованием require, поэтому не оптимизировали его под особенности конкретного способа виртуализации. Мы считаем, что такой стилистический выбор, как размещение вспомогательных функций внутри или вне главной функции, не должен иметь настолько существенного влияния на результат.Мы не знали об этой особенности модуля виртуализации Node.js, а, узнав, сочли её достаточно серьёзной для того, чтобы пересмотреть результаты. Теперь мы проводим тестирование в обычной виртуальной машине уровня ядра. Мы загружаем модули участников с помощью
require и вызываем функцию filter один раз. На каждый проход теста запускается новый процесс Node.js.К сожалению, это исправление приведёт к смене тройки лидеров. Мы приносим извинения тем, чья победа была объявлена ранее, и тем, кто изначально был лишён заслуженных призовых мест.
В тестах на производительность не встречаются символы ? в правилах
В отличие от тестов на корректность, которые призваны проверить правильность поведения программы даже в искусственно созданных редких ситуациях, тесты на производительность должны быть похожими на реальную жизнь. В частности, реальные пользователи едва ли когда-нибудь используют знак
? в правилах. Большинство правил в нашем тесте на производительность не содержат даже звёздочек, а в остальных звёздочка используется вместо всей части либо до, либо после символа @, что также отражает типичное применение этой возможности.В тестах на производительность недостаточно много правил
Даже 100 правил — многовато для типичного продвинутого пользователя почты. В отличие от числа писем, мы не ожидаем хорошей масштабируемости при росте числа правил до таких нереалистичных чисел, как, например, 1000.
В тестах на производительность недостаточно много писем
Мы решили использовать 100 000 писем, поскольку это реалистичное число для активного пользователя за год. В порядке эксперимента мы решили увеличить это число до 800 000 — бо?льшие размеры уже начинают вызывать нехватку оперативной памяти для некоторых решений при стандартных настройках V8. Увеличенный тест можно сгенерировать скриптом
generate_large_test.js с опцией xlarge. Мы прогнали на нём все корректные решения и увидели, что от увеличения объёма входных данных расстановка лидеров несколько меняется.И 100 000, и 800 000, и промежуточные значения — в принципе одинаково достойные варианты. Мы могли бы сделать выбор в пользу увеличенного теста, или же взять некое средневзвешенное значение. Однако мы решили оставить изначальный вариант с 100 000 писем, чтобы свести к минимуму изменение методики тестирования по сравнению с изначально опубликованным. Если вышеописанная проблема с виртуализацией вносила такие чудовищные искажения, что соревнование уже нельзя было назвать честным, то размер тестовых данных мог быть свободно выбран в некотором разумном диапазоне, и тот размер, который мы решили использовать, вполне разумен.
Тесты надо было публиковать заранее
Мы не публиковали тесты в начале конкурса, чтобы не создать ситуацию, при которой участники занимались бы оптимизацией под конкретные тесты, а некоторые и вовсе пытались бы обманывать тестовую систему. Скажем, увидев, что наш скрипт, генерирующий тесты на производительность, никогда не использует знак
?, а знак * ставит только в начало или конец маски, хитрый участник мог бы написать один полностью корректный вариант алгоритма на случай тестирования на корректность (если число писем невелико), а при большом числе писем переключаться на более быстрый вариант, поддерживающий только те случаи, которые встречаются в тестах на производительность.Тем не менее, мы решили в будущем публиковать больше информации о том, как будет проходить тестирование. Скажем, не показывая сами тестовые данные, мы могли бы объявить заранее их объём.
Итоги
Новая система тестирования и окончательные итоги опубликованы в репозитории на GitHub. Исправленные результаты — в следующем посте.
Ещё раз приношу извинения всем, кого затронула эта история.
Комментарии (50)
Aquahawk
12.01.2016 22:37+22habrahabr.ru/company/hola/blog/270847/#comment_8654277
Ох как точно было предсказание.
Единственный вариант который я вижу для компании чтобы сохранить лицо это выплатить обоим тройкам свои призы. Это было бы достойно. Остальное нет.
spmbt
13.01.2016 00:43На мой взгляд (не участвую в конкурсе, не знаю никого из организаторов), ситуация и её разруливание — вполне нормальные и адекватные. Дело затеяли новое для себя, не учли размах, не просчитали ошибки, они решаются в процессе возникновения, признаются. Зато, сколько людей могли заняться интересным делом! И опыт, прецедент могут использовать они же или другие. В общем, на мой взгляд, всё происходящее — положительно, и уже из-за этого несправедливо было бы требовать повышения конкурсных трат.
И другой вопрос. Как разрулить, на мой взгляд.
1) Надо тестировать в наиболее ожидаемой конфигурации тестовой среды, т.е. в той, в которой наиболее часто использовали участники — без виртуальной машины и со всеми оговоренными условиями конкурса, а остальные (размер базы, состав правил) подбирать как-то, исходя из консенсуса.
2) Опубликовать сначала уточнённые условия теста, чтобы послушать претензии.
3) Через пару дней — брать на второе тестирование и проверять вручную на наличие хаков лишь первые 10-20 результатов, сравнивая относительные перемещения мест от первого ко второму тесту. Определить лидеров в новых тестах и разрезать призы по усмоттрению и по вкусу, чисто субъективно, но уже без приёма претензий.
4) В будущем так не делать: ).
feldgendler
13.01.2016 12:57+1Как-то так и будем делать. Принципиально избавиться от багов невозможно, но постараемся делать так, чтобы сводить к минимуму репутационный ущерб от них. В частности (2) в Вашем списке.
Aquahawk
13.01.2016 14:04+4russianaicup.ru
Учитесь у них. Многоэтапность с уточнение правил, два запуска песочницы, в рантайме рейтинги и возможность править алогиртмы. Это даст не в пример лучше результат итоговый и прозрачность соревнования для участников.feldgendler
13.01.2016 14:16Спасибо, интересно.
dikkini
13.01.2016 17:41+1А можно публиковать тесты после завершения конкурса. То есть весь код уже написан и то чего вы боитесь не произойдет.
xGromMx
12.01.2016 22:42+11Как можно быть такими? Ваше слово как и ваши действие стоят ровным счетом ничего, а давайте также вам зарплаты выдавать? Ой, кажется что-то поменялось и ее отдадут другим!
mr47
12.01.2016 23:59-3Вот честно %user_name%, вы занимаетесь ерундой. Да обидно что результаты пересмотрели. Я к примеру занял там 100+ какое то место и написал результат за первые пару дней. И мне интересно было участие, а не приз/деньги/
слава/женщины.
И честно скажу результат который я думал что %user_name% или кто то напишет — каноничный результат но увы он отсутствует.
RegExp — в такой задаче зло и как мне казалось самым простым решением. Хотя по результатам так сделали все — а это плохо.
В моем представлении решением должен был быть модифицированный алгоритм расстояния Левенштейна или подобный. Он явно будет быстрее RegExp'ов. ( — На вопрос от %user_name%: «ну ты типо загнул, а почему сам не написал» — ответ: был занят очень сильно.)
Но посмотрев топовые результаты я увидел только RegExp и вариации оптимизации.
Еще раз повторюсь — если для вас %user_name% конкурс === деньги, то для вас у меня плохие новости :)
PS: Конечно не красиво получилось но признание ошибки — это половина дела. Вторая половина это принятие со стороны конкурсантов.
И опять если вы не сталкивались с таким на конкурсах то опять же, если для вас %user_name% конкурс === деньги, то для вас у меня плохие новости.
Удачи %user_name% и спасибо компании Hola за конкурс жду с еще.
hell0w0rd
13.01.2016 00:18+4Компания устраивает подобные конкурсы, вроде как, ради поиска потенциальных сотрудников. Тот факт, что это делается подобным образом — неимоверно круто, респект и побольше бы таких.
Однако то, как это делается — пугает. Я участвовал в конкурсах по программированию, везде есть песочница, куда можно залить решение и получить фидбэк. Там же тесты, там же бенчмарки, там же сравнение с другими участниками.mr47
13.01.2016 00:21-1Ну это минусы о которых говорилось не однократно в других обсуждениях их конкурсов. Они стараются но есть предположение, что делает несколько человек. Что явно сказывается на качестве конкурса.
degorov
13.01.2016 09:17Ну у меня нет regexp, например. Само по себе не сильно помогло, кстати — я в шестом десятке по старым тестам, но у меня ф-я wildcard, честно подсмотренная в исходниках OS X и портированная с Си с учётом особенностей JS, работала быстрее, чем регулярки.
mr47
13.01.2016 10:34Рекурсия тоже штука не быстрая, решение правда интересное. Жаль пока нет времени покопаться побольше :)
Sirion
13.01.2016 02:29+3Знаете, я как-то был на соревновании по русским шашкам, организованном в рекламных целях неким магазином спорт. товаров. Человек, отвечавший за организацию, вместо контрольных часов принёс секундомер. И сказал: партия будет длиться пять минут, после этого считаем шашки на доске, у кого больше — тот выиграл.
Спросите меня, пользовался ли я после этого услугами этого магазина.
Temmokan
13.01.2016 02:40+6Указывать параметры тестирования, как я понимаю — существенно. Есть разница, оптимизировать ли код под 10 правил сопоставления, под 1000 или под 1000000. Понятно, что никто не мешает выдать универсальное решение, выбирающее вариант реализации после анализа входных данных, но тут уже не будет компактности и изящества, IMNSHO.
Полагаю, резонно рассчитывать, что в следующих конкурсах как минимум следует ожидать максимально подробно описанной системы тестирования со всеми граничными параметрами, пусть без собственно комплектов данных.
К слову: если подлинной целью является поиск людей, предлагающих интересные, нешаблонные решения, то нужна как минимум ещё одна оценка, а лучше — краткий комментарий к решениям, по поводу этой их части. Как в фигурном катании, две оценки: за технику (выявляется тестами и числами) и артистизм. Будет больше стимула дополнительно стараться из любви к искусству.
И заранее поздравляю новый список призёров. :)feldgendler
13.01.2016 13:02В прошлом конкурсе было, если можно так сказать, про артистизм: github.com/hola/challenge_linked_list
Тогда претензий по итогам было гораздо больше, после чего и решили устраивать соревнование по объективно измеримому параметру.Temmokan
13.01.2016 21:02+1Так артистизм и не нужно в числах измерять. Это ж не ИзПиТал.
Выдвинуть отдельной номинацией, чтобы подчеркнуть не просто скорость кода, а умение сделать его оригинальным.
Methos
13.01.2016 08:42+3Мне кажется, что нужно брать усреднённое значение для несколько вариантов данных. Например, 20 вариантов входных данных.
Ну а то, где тестировать, через vm или require, это нужно оговаривать заранее.
Или опять же, брать среднее значение от двух вариантов.
Тогда будет не то что честно, но как-то правильно что-ли =)feldgendler
13.01.2016 13:03Дикое поведение Node.js vm — это баг. Если бы мы о нём знали заранее, ни за что не выбрали бы этот способ.
kazmiruk
13.01.2016 09:24+5Выскажу свое мнение о происходящем.
Когда был объявлен конкурс в комментариях задавалось множество вопросов. В том числе там было и про способ запуска на что последовал такой ответ:
Мы будем запускать его в виртуальной машине Node.js, где require вообще не будет.
Да, я (как и организаторы, и большинство участников) не знал о такой особенности vm. Но с другой стороны если был человек, который знал о таком нюансе и воспринял это как одно из условий, то он мог оптимизировать свой код под работу именно в таких условиях. А сейчас вдруг берут и все переигрывают не давая ему возможности исправить. Тут я считаю Hola повела себя неверно, пойдя на поводу у сообщества и решив пересмотреть результат да еще и изменив условия прогона тестов с изначальными. Признали бы свою неправоту и оставили все как есть — было бы куда лучшим вариантом.
zBit
13.01.2016 10:00Об этом нюансе не знали организаторы конкурса. Это совсем другой разговор. Если бы организатор знал о таком поведении модуля, то не ставил бы таких условий. И написано было, что в виртуальной машине NodeJS, а не в модуле vm для ноды. Приведённое выше предложение можно трактовать неоднозначно.
kazmiruk
13.01.2016 12:36+1А почему организаторы должны прислушиваться к Вашей трактовке, а не к чей-то другой? Я к примеру понял именно вариант с vm (честно, другой «виртуальной машины NodeJS» не знаю просто) и вполне мог заоптимизировать свой код под это дело, если бы знал о таких особенностях. В любом случае все были в одинаковых условиях.
feldgendler
13.01.2016 13:06+1Если бы тем, кто оптимизировал под Node.js vm, была дана возможность исправить свои решения, оптимизировав их теперь под прямую загрузку с помощью require, то что они изменили бы? Скорее всего, ничего. Node.js vm делает доступ к глобальным переменным непропорционально медленным, поэтому перенос их внутрь функции помогает. Однако без vm глобальные и локальные переменные работают примерно одинаково быстро, так что преимущества от переноса их обратно наружу нет.
kazmiruk
13.01.2016 13:18Ну так «скорее всего» или точно? А то потом 3ий раз результаты пересматривать еще решите )
Ag47
13.01.2016 09:28+3Спасибо организатором за конкурс, было очень интересно поучаствовать! Правда, в итоге выслал решение в котором был require модуля маски (забыл вставить внутрь скрипта, при тестировании разных вариантов так было удобнее), а потом еще оказалось, что маски должны быть регистрозависимы, в общем, участвую вне конкурса=)
Идее, что если мы проверяем одни правила и они подходят, то другие проверять совсем не обязательно пришла достаточно быстро. Первоначально планировал строить дерево, смотрю подходят ли маски друг к другу, возможны варианты, что одна как бы более общая, будет родителем, вторая частная дочерним элементом, если они обе подходят друг к другу или не подходят, то будут на одном уровне. В итоге в узлах стоят маски, если она подходит, то смотрим подходят ли дочерние и т.д. Другое дело, что в общем случае дерево получалось слишком плоское, так что какого-то толка от него ждать не приходилось, и на нем приходилось делать слишком много сравнений масок между собой. На сотне правил надо будет посмотреть, может не все так плохо.
Далее была идея строить дерево по символам масок, например, узел 'a', в нем маски начинающиеся на 'а', в его дочернем узле 'b' будут соответственно те, что начинаются на 'ab' и т.д. Вопросительный знак тоже мог быть узлом, в который мы просто всегда входим, а вот звездочка это головная боль, после неё была идея менять порядок на обратный и смотреть символы с конца строки снова до звездочки. Берем емейл и идем по его символам выбирая из дерева подходящие правила.
Упрощенная версия этой идеи это просто классифицировать по первому символу. Берем емейл и проверяем правила на этот символ, еще все начинающиеся на '*' и '?'. Маски делятся на те, где проверяется только from, где только to и оба. Если брать первый и последний символ, то вариантов проверки различных наборов правил уже набегало 81. Производительность в итоге упала, и с полным деревом решено было не заморачиваться.
Далее приправил мемоизацией результата для правила целиком и проверки правил без специальных символов простым сравнением строк. Мемозиация результата для каждого правила показала себя не очень хорошо, так как требуется слишком много памяти и все эти накладные расходы по проверке наличия результата делают результат еще хуже.
Замена регулярок на свою функцию, в общем случае, себя не оправдала, хождение по строке достаточно медленное в js. В си чтобы сравнить строки, ты идешь просто по символам и сравниваешь, в js можно сравнить их целиком, а можно самому по символьно, и тут второй вариант уже медленней. Аналогично, регекспы обрабатывали строку быстрее, чем своя функция проверки паттерна. Наверное, если как в опубликованных тестовых данных, вопросительного знака не будет, а звездочка только в конце или начале это может быть быстрее.
Проблема, которую мне так и не удалось решить это как мне отсортировать результаты действия правил. Дело в том, что все эти деревья и классификации возвращают в итоге возможно подходящие правила в произвольном порядке, а надо чтобы действия применялись в порядке следования правил. Очевидное решение сортировка работает недостаточно быстро, быстрее оказалось сохранять action походящего правила в хеш-таблицу, где ключом будет индекс правила, а значением value. Далее получить все ключи, они будут в порядке возрастания, что нам и надо, пройтись по ним и составить массив. Другое дело, что это какой-то костыль, который съедает 10-15% времени. Может сообщество знает как это можно было бы решить?
degorov
13.01.2016 09:38О, мы с Вами думали практически одинаково чуть ли не по всем пунктам!
> Замена регулярок на свою функцию, в общем случае, себя не оправдала, хождение по строке достаточно медленное в js.
А я ходил не по строке, а по массиву .split('') — помогло здорово.
Про то, как проверять пересечения глобов там ниже в моём комменте есть хороший линк на SO по теме.
Про мемоизацию у меня впечатления те же — я пробовал играться с нативным Map из ES6 — тоже не помогло.
И по последнему абзацу мне тоже интересно :)Ag47
13.01.2016 10:36Насчет 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 ~1650degorov
13.01.2016 10:56У меня если убрать split во всех трёх местах, разница получается порядка 10%, что не радикально, но статистически значимо.
Там вроде генератор с фиксированным зерном поэтому данные одинаковые у вас и у них.
degorov
13.01.2016 09:32+1Я не знаю, насколько это релевантно теме, но это максимум до чего я смог додуматься, хотя в итоге отправил другое решение. Я решил, что есть смысл проверить пересекаемость правил. Ну то есть я предположил, что правила будут составляться так, что если адрес соответствует одному правилу, то он гарантированно уже не соответствует некоторым другим правилам. Например, если адрес соответствует *@mail.ru то он уже никак не может соответствовать *@yandex.ru и так далее. Оказалось, что задача поиска пересечений в глобах вполне себе известна и на том же SO есть обсуждение, в том числе даже нашёлся готовый код на JS. Там даже чуть более сложный вариант, там допустимы ещё [], я для себя выпилил лишний функционал. Мне не показалось корректным отправлять фактически чужой код во-первых, плюс на некоторых тестах (где пересекающихся правило мало) вариант в лоб работал быстрей. Но если кому интересно — советую тот jsFiddle поглядеть — там круто :)
Find_the_truth
13.01.2016 10:55В любом конкурсе есть участники, а есть сообщество, которое не участвует, но всячески старается научить/дать совет/показать/надоумить (подчеркните нужное). Если уж взялись за конкурс, то ведите его до конца по СВОИМ правилам, не прислушиваясь к тем, кто «занят, работает на важным проектом, а тут, так, в свободную секунду отвлекся и решил показать всем, как всё должно работать», кто бы всё это задание «сделал вообще в одну строку, но ему неинтересно» и т.д, т.п. ТЫСЯЧИ их. В другой раз, как мне кажется, проще не проводить конкурсы, а выбрать пару-тройку программеров и написать им задание в личку. То есть провести закрытый конкурс. Иначе стараешься для всех, организовываешь, а тебя потом учат уму-разуму, еще и агрятся все, кому не лень.
feldgendler
13.01.2016 13:10+3Если Вам кажется, что мы пошли на пересмотр результатов, потому что поддались давлению, то это не так. Мы решили это сделать, потому что нам указали на баг, из-за которого судейство становится нечестным. Если бы мы обнаружили его сами, то всё равно пересмотрели бы результаты.
Find_the_truth
13.01.2016 13:32+3Если бы вы его обнаружили сами, было бы еще интереснее наблюдать за этим. Потому что на данный момент сообщество разделилось на два лагеря: за первый вариант, за второй вариант. Если бы вы сами что-то изменили, это бы вызывало на вашу голову гнев обеих сторон. Хотя, по мне, так и сейчас вам не сладко.
feldgendler
13.01.2016 13:34+3Всегда лучше не допустить ошибки, чем допустить. Но если уж допустили, лучше исправить, чем настаивать на ошибочном варианте.
Alex_At_Net
13.01.2016 14:44+4Это все правильно. Но в момент объявления результатов вы обязуетесь выполнить условия конкурса. Считайте, отдали приз. Он теперь не ваш. Исправляйте на здоровье, но не за счет чужих денег и репутации.
feldgendler
13.01.2016 14:57На печально известном конкурсе красоты, где ведущий неправильно назвал имя победительницы, тоже надо было вручить приз обеим?
www.foxnews.com/entertainment/2015/12/21/miss-universe-host-makes-huge-gaffe-names-wrong-winner-pageantAlex_At_Net
13.01.2016 15:13+3Я понимаю, что для вас это сейчас больная тема и вы в непростой ситуации. Естественно примеров в истории будет масса с разными вариантами похожей ситуации. Где-то дали два приза, где-то поменяли, где-то кто-то застрелился. Не в этом суть.
Суть в том, что в данной конкретной ситуации у вас есть некоторый диапазон возможностей с разными последствиями. На мой взгляд, вы выбираете очевидно невыгодный для компании в первую очередь, который базируется на некорректном понимании психологии участников. Я пытаюсь вам помочь и скорректировать события в том направлении, которое считаю правильным. Может, как обычно, зря. Но пытаюсь. Вот, в общем, и все.
Alex_At_Net
13.01.2016 14:36+6Думаю, как участник конкурса у менять есть право высказать свое мнение на счет пересмотра результатов.
Согласно публичному договору, Hola объявляет конкурс на своих условиях и объявляет победителей 8 числа. Все участники соглашаются с этим.
Конкурс проведен, результаты объявлены. Всё. Финиш.
Все улучшения, обсуждения и т.п. — в следующих конкурсах. Включая признание своей вины если что-то не так.
Лучше бы еще один конкурс сразу объявили с другим заданием, улучшенной методикой и т.п. :-)
Это — честно и по договоренности.
В самом крайнем случае, обратиться лично к выбранным победителям и объяснить ситуацию, попробовать выработать совместное решение. Что сейчас происходит является очень нехорошим по отношению к объявленным победителям. Не надо так.
datacompboy
ууу… судя по тому, что некоторым так нужны деньги, что началось козыряние цитатами законов, скоро здесь будет жарко…
mark_ablov
Ну дык, по нынешним-то временам $1500 вполне ок сумма.
datacompboy
Напомню, что цель конкурса — найти программистов, кому предложить высокооплачиваемую удалённую работу. Причем оффер независит от результата в таблице, а зависит от мышления, продемонстрированного при решении.
В комментариях видно, что подход был определённо замечен и учтен.
И вот тут своим выступлением человек явно перечеркивает не только эту возможность, но и много других возможных работ, кто не поленится копнуть в историю. Не знаю, хорошо это, плохо ли, или вообще не вариант — но подобная публичность хороша только для политиков и шоуменов.
deniskreshikhin
Хотя я не ищу работу, но если бы я и стал искать, то не вижу ничего плохого, в том что кому-то я могу не понравится. Или даже всем!
Это нормальная ситуация. Человек должен оставаться самим собой, а не подстраиваться под всех. Не будет работы прогером, пойду брюкву выращивать и свиней пасти. Вот Диоклетиан же променял императорство на огород с капустой, а императорский трон вроде даже и в Гугл не предлагают.
deniskreshikhin
Что за рабское мышление?
Т.к. возмущался только я в принципе по поводу пересмотра, то отвечу.
Я всегда возмущаюсь когда сталкиваюсь с нарушением моих прав.
В правилах нет ничего про возможность пересмотра результатов, ни про то что опубликованные результаты имеют предварительный характер.
Если бы в правилах был описан порядок пересмотра, я бы не возмущался.
А так я предупредил организаторов, что оставляю за собой право опротестовать их поведение в суде.
И новых результатов, как уже объявленный победитель, я не признаю.
datacompboy
Качество вашего решения изменилось от исправления ошибки тестирования? Нет.
Ваше решение внезапно оказалось не лучшим? Да.
Знали ли вы, что другие решения лучше, но ваше больше подходит под ту ошибку? Нет.
Итого, ваше решение не лучшее. Продолжая требовать себе обратно вы либо расписываетесь в том, что уже успели на эти деньги что-то взять (долг, кредит, опционы, пельмени — неважно) и теперь попали, либо расписываетесь в том, что вам просто плевать на качество вашего решения, лишь бы проскочить.
deniskreshikhin
Ну что тут скажешь, именно про вас видимо писал Чернышевский «сверху донизу — все рабы», раз уж вы перешли на личность.
Раб всегда беспокоится в первую очередь о выгоде хозяина и тех кто выше по положению, а не своей.
Свободный человек, не раб, заботится в первую очередь о своей прямой выгоде и своих правах.
Так что не вижу ничего дурного в том что защищаю свои интересы.
Опять же, ничто не мешает провести второй раунд, и выплатить призы еще раз. Компания Hola от этого не разориться. А те результаты оставить как есть, т.к. они не имеют права их пересматривать. По их же правилам.
datacompboy
Да, я раб. Раб совести. И да, меня тоже интересуют свои интересы.
Поэтому тогда, когда это может нанести ущерб репутации я сперва решаю вопрос лично.
Впрочем, пока, я надеюсь, что вы сперва пытались провести досудебное урегулирование лично, а только потом уже подали в суд.
Кстати, номер дела не назовёте? Я с удовольствием послежу за ним.
OnYourLips
Поставьте себя на место работодателя. Вы бы хотели нанять руководителя, который будет следовать вашим интересы, или мягкотелого сопляка, который позволит всем остальным прогибать себя?
> что вы сперва пытались провести досудебное урегулирование лично
Я тоже на это надеюсь.
И надеюсь, что он получит свои деньги.