Комментарии 50
ууу… судя по тому, что некоторым так нужны деньги, что началось козыряние цитатами законов, скоро здесь будет жарко…
Ну дык, по нынешним-то временам $1500 вполне ок сумма.
Напомню, что цель конкурса — найти программистов, кому предложить высокооплачиваемую удалённую работу. Причем оффер независит от результата в таблице, а зависит от мышления, продемонстрированного при решении.
В комментариях видно, что подход был определённо замечен и учтен.
И вот тут своим выступлением человек явно перечеркивает не только эту возможность, но и много других возможных работ, кто не поленится копнуть в историю. Не знаю, хорошо это, плохо ли, или вообще не вариант — но подобная публичность хороша только для политиков и шоуменов.
В комментариях видно, что подход был определённо замечен и учтен.
И вот тут своим выступлением человек явно перечеркивает не только эту возможность, но и много других возможных работ, кто не поленится копнуть в историю. Не знаю, хорошо это, плохо ли, или вообще не вариант — но подобная публичность хороша только для политиков и шоуменов.
НЛО прилетело и опубликовало эту надпись здесь
Качество вашего решения изменилось от исправления ошибки тестирования? Нет.
Ваше решение внезапно оказалось не лучшим? Да.
Знали ли вы, что другие решения лучше, но ваше больше подходит под ту ошибку? Нет.
Итого, ваше решение не лучшее. Продолжая требовать себе обратно вы либо расписываетесь в том, что уже успели на эти деньги что-то взять (долг, кредит, опционы, пельмени — неважно) и теперь попали, либо расписываетесь в том, что вам просто плевать на качество вашего решения, лишь бы проскочить.
Ваше решение внезапно оказалось не лучшим? Да.
Знали ли вы, что другие решения лучше, но ваше больше подходит под ту ошибку? Нет.
Итого, ваше решение не лучшее. Продолжая требовать себе обратно вы либо расписываетесь в том, что уже успели на эти деньги что-то взять (долг, кредит, опционы, пельмени — неважно) и теперь попали, либо расписываетесь в том, что вам просто плевать на качество вашего решения, лишь бы проскочить.
НЛО прилетело и опубликовало эту надпись здесь
Да, я раб. Раб совести. И да, меня тоже интересуют свои интересы.
Поэтому тогда, когда это может нанести ущерб репутации я сперва решаю вопрос лично.
Впрочем, пока, я надеюсь, что вы сперва пытались провести досудебное урегулирование лично, а только потом уже подали в суд.
Кстати, номер дела не назовёте? Я с удовольствием послежу за ним.
Поэтому тогда, когда это может нанести ущерб репутации я сперва решаю вопрос лично.
Впрочем, пока, я надеюсь, что вы сперва пытались провести досудебное урегулирование лично, а только потом уже подали в суд.
Кстати, номер дела не назовёте? Я с удовольствием послежу за ним.
habrahabr.ru/company/hola/blog/270847/#comment_8654277
Ох как точно было предсказание.
Единственный вариант который я вижу для компании чтобы сохранить лицо это выплатить обоим тройкам свои призы. Это было бы достойно. Остальное нет.
Ох как точно было предсказание.
Единственный вариант который я вижу для компании чтобы сохранить лицо это выплатить обоим тройкам свои призы. Это было бы достойно. Остальное нет.
На мой взгляд (не участвую в конкурсе, не знаю никого из организаторов), ситуация и её разруливание — вполне нормальные и адекватные. Дело затеяли новое для себя, не учли размах, не просчитали ошибки, они решаются в процессе возникновения, признаются. Зато, сколько людей могли заняться интересным делом! И опыт, прецедент могут использовать они же или другие. В общем, на мой взгляд, всё происходящее — положительно, и уже из-за этого несправедливо было бы требовать повышения конкурсных трат.
И другой вопрос. Как разрулить, на мой взгляд.
1) Надо тестировать в наиболее ожидаемой конфигурации тестовой среды, т.е. в той, в которой наиболее часто использовали участники — без виртуальной машины и со всеми оговоренными условиями конкурса, а остальные (размер базы, состав правил) подбирать как-то, исходя из консенсуса.
2) Опубликовать сначала уточнённые условия теста, чтобы послушать претензии.
3) Через пару дней — брать на второе тестирование и проверять вручную на наличие хаков лишь первые 10-20 результатов, сравнивая относительные перемещения мест от первого ко второму тесту. Определить лидеров в новых тестах и разрезать призы по усмоттрению и по вкусу, чисто субъективно, но уже без приёма претензий.
4) В будущем так не делать: ).
И другой вопрос. Как разрулить, на мой взгляд.
1) Надо тестировать в наиболее ожидаемой конфигурации тестовой среды, т.е. в той, в которой наиболее часто использовали участники — без виртуальной машины и со всеми оговоренными условиями конкурса, а остальные (размер базы, состав правил) подбирать как-то, исходя из консенсуса.
2) Опубликовать сначала уточнённые условия теста, чтобы послушать претензии.
3) Через пару дней — брать на второе тестирование и проверять вручную на наличие хаков лишь первые 10-20 результатов, сравнивая относительные перемещения мест от первого ко второму тесту. Определить лидеров в новых тестах и разрезать призы по усмоттрению и по вкусу, чисто субъективно, но уже без приёма претензий.
4) В будущем так не делать: ).
Как-то так и будем делать. Принципиально избавиться от багов невозможно, но постараемся делать так, чтобы сводить к минимуму репутационный ущерб от них. В частности (2) в Вашем списке.
russianaicup.ru
Учитесь у них. Многоэтапность с уточнение правил, два запуска песочницы, в рантайме рейтинги и возможность править алогиртмы. Это даст не в пример лучше результат итоговый и прозрачность соревнования для участников.
Учитесь у них. Многоэтапность с уточнение правил, два запуска песочницы, в рантайме рейтинги и возможность править алогиртмы. Это даст не в пример лучше результат итоговый и прозрачность соревнования для участников.
Как можно быть такими? Ваше слово как и ваши действие стоят ровным счетом ничего, а давайте также вам зарплаты выдавать? Ой, кажется что-то поменялось и ее отдадут другим!
Вот честно %user_name%, вы занимаетесь ерундой. Да обидно что результаты пересмотрели. Я к примеру занял там 100+ какое то место и написал результат за первые пару дней. И мне интересно было участие, а не приз/деньги/слава/женщины.
И честно скажу результат который я думал что %user_name% или кто то напишет — каноничный результат но увы он отсутствует.
RegExp — в такой задаче зло и как мне казалось самым простым решением. Хотя по результатам так сделали все — а это плохо.
В моем представлении решением должен был быть модифицированный алгоритм расстояния Левенштейна или подобный. Он явно будет быстрее RegExp'ов. ( — На вопрос от %user_name%: «ну ты типо загнул, а почему сам не написал» — ответ: был занят очень сильно.)
Но посмотрев топовые результаты я увидел только RegExp и вариации оптимизации.
Еще раз повторюсь — если для вас %user_name% конкурс === деньги, то для вас у меня плохие новости :)
PS: Конечно не красиво получилось но признание ошибки — это половина дела. Вторая половина это принятие со стороны конкурсантов.
И опять если вы не сталкивались с таким на конкурсах то опять же, если для вас %user_name% конкурс === деньги, то для вас у меня плохие новости.
Удачи %user_name% и спасибо компании Hola за конкурс жду с еще.
И честно скажу результат который я думал что %user_name% или кто то напишет — каноничный результат но увы он отсутствует.
RegExp — в такой задаче зло и как мне казалось самым простым решением. Хотя по результатам так сделали все — а это плохо.
В моем представлении решением должен был быть модифицированный алгоритм расстояния Левенштейна или подобный. Он явно будет быстрее RegExp'ов. ( — На вопрос от %user_name%: «ну ты типо загнул, а почему сам не написал» — ответ: был занят очень сильно.)
Но посмотрев топовые результаты я увидел только RegExp и вариации оптимизации.
Еще раз повторюсь — если для вас %user_name% конкурс === деньги, то для вас у меня плохие новости :)
PS: Конечно не красиво получилось но признание ошибки — это половина дела. Вторая половина это принятие со стороны конкурсантов.
И опять если вы не сталкивались с таким на конкурсах то опять же, если для вас %user_name% конкурс === деньги, то для вас у меня плохие новости.
Удачи %user_name% и спасибо компании Hola за конкурс жду с еще.
Компания устраивает подобные конкурсы, вроде как, ради поиска потенциальных сотрудников. Тот факт, что это делается подобным образом — неимоверно круто, респект и побольше бы таких.
Однако то, как это делается — пугает. Я участвовал в конкурсах по программированию, везде есть песочница, куда можно залить решение и получить фидбэк. Там же тесты, там же бенчмарки, там же сравнение с другими участниками.
Однако то, как это делается — пугает. Я участвовал в конкурсах по программированию, везде есть песочница, куда можно залить решение и получить фидбэк. Там же тесты, там же бенчмарки, там же сравнение с другими участниками.
НЛО прилетело и опубликовало эту надпись здесь
Знаете, я как-то был на соревновании по русским шашкам, организованном в рекламных целях неким магазином спорт. товаров. Человек, отвечавший за организацию, вместо контрольных часов принёс секундомер. И сказал: партия будет длиться пять минут, после этого считаем шашки на доске, у кого больше — тот выиграл.
Спросите меня, пользовался ли я после этого услугами этого магазина.
Спросите меня, пользовался ли я после этого услугами этого магазина.
Указывать параметры тестирования, как я понимаю — существенно. Есть разница, оптимизировать ли код под 10 правил сопоставления, под 1000 или под 1000000. Понятно, что никто не мешает выдать универсальное решение, выбирающее вариант реализации после анализа входных данных, но тут уже не будет компактности и изящества, IMNSHO.
Полагаю, резонно рассчитывать, что в следующих конкурсах как минимум следует ожидать максимально подробно описанной системы тестирования со всеми граничными параметрами, пусть без собственно комплектов данных.
К слову: если подлинной целью является поиск людей, предлагающих интересные, нешаблонные решения, то нужна как минимум ещё одна оценка, а лучше — краткий комментарий к решениям, по поводу этой их части. Как в фигурном катании, две оценки: за технику (выявляется тестами и числами) и артистизм. Будет больше стимула дополнительно стараться из любви к искусству.
И заранее поздравляю новый список призёров. :)
Полагаю, резонно рассчитывать, что в следующих конкурсах как минимум следует ожидать максимально подробно описанной системы тестирования со всеми граничными параметрами, пусть без собственно комплектов данных.
К слову: если подлинной целью является поиск людей, предлагающих интересные, нешаблонные решения, то нужна как минимум ещё одна оценка, а лучше — краткий комментарий к решениям, по поводу этой их части. Как в фигурном катании, две оценки: за технику (выявляется тестами и числами) и артистизм. Будет больше стимула дополнительно стараться из любви к искусству.
И заранее поздравляю новый список призёров. :)
В прошлом конкурсе было, если можно так сказать, про артистизм: github.com/hola/challenge_linked_list
Тогда претензий по итогам было гораздо больше, после чего и решили устраивать соревнование по объективно измеримому параметру.
Тогда претензий по итогам было гораздо больше, после чего и решили устраивать соревнование по объективно измеримому параметру.
Мне кажется, что нужно брать усреднённое значение для несколько вариантов данных. Например, 20 вариантов входных данных.
Ну а то, где тестировать, через vm или require, это нужно оговаривать заранее.
Или опять же, брать среднее значение от двух вариантов.
Тогда будет не то что честно, но как-то правильно что-ли =)
Ну а то, где тестировать, через vm или require, это нужно оговаривать заранее.
Или опять же, брать среднее значение от двух вариантов.
Тогда будет не то что честно, но как-то правильно что-ли =)
Выскажу свое мнение о происходящем.
Когда был объявлен конкурс в комментариях задавалось множество вопросов. В том числе там было и про способ запуска на что последовал такой ответ:
Да, я (как и организаторы, и большинство участников) не знал о такой особенности vm. Но с другой стороны если был человек, который знал о таком нюансе и воспринял это как одно из условий, то он мог оптимизировать свой код под работу именно в таких условиях. А сейчас вдруг берут и все переигрывают не давая ему возможности исправить. Тут я считаю Hola повела себя неверно, пойдя на поводу у сообщества и решив пересмотреть результат да еще и изменив условия прогона тестов с изначальными. Признали бы свою неправоту и оставили все как есть — было бы куда лучшим вариантом.
Когда был объявлен конкурс в комментариях задавалось множество вопросов. В том числе там было и про способ запуска на что последовал такой ответ:
Мы будем запускать его в виртуальной машине Node.js, где require вообще не будет.
Да, я (как и организаторы, и большинство участников) не знал о такой особенности vm. Но с другой стороны если был человек, который знал о таком нюансе и воспринял это как одно из условий, то он мог оптимизировать свой код под работу именно в таких условиях. А сейчас вдруг берут и все переигрывают не давая ему возможности исправить. Тут я считаю Hola повела себя неверно, пойдя на поводу у сообщества и решив пересмотреть результат да еще и изменив условия прогона тестов с изначальными. Признали бы свою неправоту и оставили все как есть — было бы куда лучшим вариантом.
Об этом нюансе не знали организаторы конкурса. Это совсем другой разговор. Если бы организатор знал о таком поведении модуля, то не ставил бы таких условий. И написано было, что в виртуальной машине NodeJS, а не в модуле vm для ноды. Приведённое выше предложение можно трактовать неоднозначно.
А почему организаторы должны прислушиваться к Вашей трактовке, а не к чей-то другой? Я к примеру понял именно вариант с vm (честно, другой «виртуальной машины NodeJS» не знаю просто) и вполне мог заоптимизировать свой код под это дело, если бы знал о таких особенностях. В любом случае все были в одинаковых условиях.
Если бы тем, кто оптимизировал под Node.js vm, была дана возможность исправить свои решения, оптимизировав их теперь под прямую загрузку с помощью require, то что они изменили бы? Скорее всего, ничего. Node.js vm делает доступ к глобальным переменным непропорционально медленным, поэтому перенос их внутрь функции помогает. Однако без vm глобальные и локальные переменные работают примерно одинаково быстро, так что преимущества от переноса их обратно наружу нет.
Спасибо организатором за конкурс, было очень интересно поучаствовать! Правда, в итоге выслал решение в котором был require модуля маски (забыл вставить внутрь скрипта, при тестировании разных вариантов так было удобнее), а потом еще оказалось, что маски должны быть регистрозависимы, в общем, участвую вне конкурса=)
Идее, что если мы проверяем одни правила и они подходят, то другие проверять совсем не обязательно пришла достаточно быстро. Первоначально планировал строить дерево, смотрю подходят ли маски друг к другу, возможны варианты, что одна как бы более общая, будет родителем, вторая частная дочерним элементом, если они обе подходят друг к другу или не подходят, то будут на одном уровне. В итоге в узлах стоят маски, если она подходит, то смотрим подходят ли дочерние и т.д. Другое дело, что в общем случае дерево получалось слишком плоское, так что какого-то толка от него ждать не приходилось, и на нем приходилось делать слишком много сравнений масок между собой. На сотне правил надо будет посмотреть, может не все так плохо.
Далее была идея строить дерево по символам масок, например, узел 'a', в нем маски начинающиеся на 'а', в его дочернем узле 'b' будут соответственно те, что начинаются на 'ab' и т.д. Вопросительный знак тоже мог быть узлом, в который мы просто всегда входим, а вот звездочка это головная боль, после неё была идея менять порядок на обратный и смотреть символы с конца строки снова до звездочки. Берем емейл и идем по его символам выбирая из дерева подходящие правила.
Упрощенная версия этой идеи это просто классифицировать по первому символу. Берем емейл и проверяем правила на этот символ, еще все начинающиеся на '*' и '?'. Маски делятся на те, где проверяется только from, где только to и оба. Если брать первый и последний символ, то вариантов проверки различных наборов правил уже набегало 81. Производительность в итоге упала, и с полным деревом решено было не заморачиваться.
Далее приправил мемоизацией результата для правила целиком и проверки правил без специальных символов простым сравнением строк. Мемозиация результата для каждого правила показала себя не очень хорошо, так как требуется слишком много памяти и все эти накладные расходы по проверке наличия результата делают результат еще хуже.
Замена регулярок на свою функцию, в общем случае, себя не оправдала, хождение по строке достаточно медленное в js. В си чтобы сравнить строки, ты идешь просто по символам и сравниваешь, в js можно сравнить их целиком, а можно самому по символьно, и тут второй вариант уже медленней. Аналогично, регекспы обрабатывали строку быстрее, чем своя функция проверки паттерна. Наверное, если как в опубликованных тестовых данных, вопросительного знака не будет, а звездочка только в конце или начале это может быть быстрее.
Проблема, которую мне так и не удалось решить это как мне отсортировать результаты действия правил. Дело в том, что все эти деревья и классификации возвращают в итоге возможно подходящие правила в произвольном порядке, а надо чтобы действия применялись в порядке следования правил. Очевидное решение сортировка работает недостаточно быстро, быстрее оказалось сохранять action походящего правила в хеш-таблицу, где ключом будет индекс правила, а значением value. Далее получить все ключи, они будут в порядке возрастания, что нам и надо, пройтись по ним и составить массив. Другое дело, что это какой-то костыль, который съедает 10-15% времени. Может сообщество знает как это можно было бы решить?
Идее, что если мы проверяем одни правила и они подходят, то другие проверять совсем не обязательно пришла достаточно быстро. Первоначально планировал строить дерево, смотрю подходят ли маски друг к другу, возможны варианты, что одна как бы более общая, будет родителем, вторая частная дочерним элементом, если они обе подходят друг к другу или не подходят, то будут на одном уровне. В итоге в узлах стоят маски, если она подходит, то смотрим подходят ли дочерние и т.д. Другое дело, что в общем случае дерево получалось слишком плоское, так что какого-то толка от него ждать не приходилось, и на нем приходилось делать слишком много сравнений масок между собой. На сотне правил надо будет посмотреть, может не все так плохо.
Далее была идея строить дерево по символам масок, например, узел 'a', в нем маски начинающиеся на 'а', в его дочернем узле 'b' будут соответственно те, что начинаются на 'ab' и т.д. Вопросительный знак тоже мог быть узлом, в который мы просто всегда входим, а вот звездочка это головная боль, после неё была идея менять порядок на обратный и смотреть символы с конца строки снова до звездочки. Берем емейл и идем по его символам выбирая из дерева подходящие правила.
Упрощенная версия этой идеи это просто классифицировать по первому символу. Берем емейл и проверяем правила на этот символ, еще все начинающиеся на '*' и '?'. Маски делятся на те, где проверяется только from, где только to и оба. Если брать первый и последний символ, то вариантов проверки различных наборов правил уже набегало 81. Производительность в итоге упала, и с полным деревом решено было не заморачиваться.
Далее приправил мемоизацией результата для правила целиком и проверки правил без специальных символов простым сравнением строк. Мемозиация результата для каждого правила показала себя не очень хорошо, так как требуется слишком много памяти и все эти накладные расходы по проверке наличия результата делают результат еще хуже.
Замена регулярок на свою функцию, в общем случае, себя не оправдала, хождение по строке достаточно медленное в js. В си чтобы сравнить строки, ты идешь просто по символам и сравниваешь, в js можно сравнить их целиком, а можно самому по символьно, и тут второй вариант уже медленней. Аналогично, регекспы обрабатывали строку быстрее, чем своя функция проверки паттерна. Наверное, если как в опубликованных тестовых данных, вопросительного знака не будет, а звездочка только в конце или начале это может быть быстрее.
Проблема, которую мне так и не удалось решить это как мне отсортировать результаты действия правил. Дело в том, что все эти деревья и классификации возвращают в итоге возможно подходящие правила в произвольном порядке, а надо чтобы действия применялись в порядке следования правил. Очевидное решение сортировка работает недостаточно быстро, быстрее оказалось сохранять action походящего правила в хеш-таблицу, где ключом будет индекс правила, а значением value. Далее получить все ключи, они будут в порядке возрастания, что нам и надо, пройтись по ним и составить массив. Другое дело, что это какой-то костыль, который съедает 10-15% времени. Может сообщество знает как это можно было бы решить?
НЛО прилетело и опубликовало эту надпись здесь
Насчет 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
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
НЛО прилетело и опубликовало эту надпись здесь
В любом конкурсе есть участники, а есть сообщество, которое не участвует, но всячески старается научить/дать совет/показать/надоумить (подчеркните нужное). Если уж взялись за конкурс, то ведите его до конца по СВОИМ правилам, не прислушиваясь к тем, кто «занят, работает на важным проектом, а тут, так, в свободную секунду отвлекся и решил показать всем, как всё должно работать», кто бы всё это задание «сделал вообще в одну строку, но ему неинтересно» и т.д, т.п. ТЫСЯЧИ их. В другой раз, как мне кажется, проще не проводить конкурсы, а выбрать пару-тройку программеров и написать им задание в личку. То есть провести закрытый конкурс. Иначе стараешься для всех, организовываешь, а тебя потом учат уму-разуму, еще и агрятся все, кому не лень.
Если бы вы его обнаружили сами, было бы еще интереснее наблюдать за этим. Потому что на данный момент сообщество разделилось на два лагеря: за первый вариант, за второй вариант. Если бы вы сами что-то изменили, это бы вызывало на вашу голову гнев обеих сторон. Хотя, по мне, так и сейчас вам не сладко.
Всегда лучше не допустить ошибки, чем допустить. Но если уж допустили, лучше исправить, чем настаивать на ошибочном варианте.
Это все правильно. Но в момент объявления результатов вы обязуетесь выполнить условия конкурса. Считайте, отдали приз. Он теперь не ваш. Исправляйте на здоровье, но не за счет чужих денег и репутации.
На печально известном конкурсе красоты, где ведущий неправильно назвал имя победительницы, тоже надо было вручить приз обеим?
www.foxnews.com/entertainment/2015/12/21/miss-universe-host-makes-huge-gaffe-names-wrong-winner-pageant
www.foxnews.com/entertainment/2015/12/21/miss-universe-host-makes-huge-gaffe-names-wrong-winner-pageant
Я понимаю, что для вас это сейчас больная тема и вы в непростой ситуации. Естественно примеров в истории будет масса с разными вариантами похожей ситуации. Где-то дали два приза, где-то поменяли, где-то кто-то застрелился. Не в этом суть.
Суть в том, что в данной конкретной ситуации у вас есть некоторый диапазон возможностей с разными последствиями. На мой взгляд, вы выбираете очевидно невыгодный для компании в первую очередь, который базируется на некорректном понимании психологии участников. Я пытаюсь вам помочь и скорректировать события в том направлении, которое считаю правильным. Может, как обычно, зря. Но пытаюсь. Вот, в общем, и все.
Суть в том, что в данной конкретной ситуации у вас есть некоторый диапазон возможностей с разными последствиями. На мой взгляд, вы выбираете очевидно невыгодный для компании в первую очередь, который базируется на некорректном понимании психологии участников. Я пытаюсь вам помочь и скорректировать события в том направлении, которое считаю правильным. Может, как обычно, зря. Но пытаюсь. Вот, в общем, и все.
Думаю, как участник конкурса у менять есть право высказать свое мнение на счет пересмотра результатов.
Согласно публичному договору, Hola объявляет конкурс на своих условиях и объявляет победителей 8 числа. Все участники соглашаются с этим.
Конкурс проведен, результаты объявлены. Всё. Финиш.
Все улучшения, обсуждения и т.п. — в следующих конкурсах. Включая признание своей вины если что-то не так.
Лучше бы еще один конкурс сразу объявили с другим заданием, улучшенной методикой и т.п. :-)
Это — честно и по договоренности.
В самом крайнем случае, обратиться лично к выбранным победителям и объяснить ситуацию, попробовать выработать совместное решение. Что сейчас происходит является очень нехорошим по отношению к объявленным победителям. Не надо так.
Согласно публичному договору, Hola объявляет конкурс на своих условиях и объявляет победителей 8 числа. Все участники соглашаются с этим.
Конкурс проведен, результаты объявлены. Всё. Финиш.
Все улучшения, обсуждения и т.п. — в следующих конкурсах. Включая признание своей вины если что-то не так.
Лучше бы еще один конкурс сразу объявили с другим заданием, улучшенной методикой и т.п. :-)
Это — честно и по договоренности.
В самом крайнем случае, обратиться лично к выбранным победителям и объяснить ситуацию, попробовать выработать совместное решение. Что сейчас происходит является очень нехорошим по отношению к объявленным победителям. Не надо так.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О пересмотре результатов конкурса по программированию на JS