Comments 52
За две недели это всё успеть?? Прямо как ТЗ к госзаказам, чтобы выбрать «нужного» поставщика.
Сейчас за несколько дней мы наберем участников, а потом все одновременно начнут разработку. Сделать то нужно не много. Сложно будет реализовать только поиск, я думаю. И все-таки это игра, а не разработка сложного коммерческого HL проекта.
Вы не можете просматривать данную страницу из-за наследованных ограничений
Ограничения уровня страницы были применены к предку текущей страницы. Эти ограничения лимитируют доступ только текущему пользователю(ям) или группе(ам) и применимы ко всем страницам в иерархии под предком.
Ограничения уровня страницы были применены к предку текущей страницы. Эти ограничения лимитируют доступ только текущему пользователю(ям) или группе(ам) и применимы ко всем страницам в иерархии под предком.
Облако тегов пересчитывается после каждой статьи?
Да. Визуализация (размер) тега на странице значения большого не играет, но вот то, что новый тег должен в облаке появиться — важно. Как минимум придется сбрасывать кеш страницы облака тегов :)
Ок. Еще вопросы:
1. распределение между запросами разного типа
2. критерии оценки, в частности, задержка против объема данных
3. предполагаемое распределение запросов между данными (аквтивно смотрим последнее, активно смотрим популярное, тупо долбим все равномерно)
1. распределение между запросами разного типа
2. критерии оценки, в частности, задержка против объема данных
3. предполагаемое распределение запросов между данными (аквтивно смотрим последнее, активно смотрим популярное, тупо долбим все равномерно)
Хорошие вопросы.
Я обязательно отвечу на них, скорее всего в Wiki, а тут обязательно оставлю ссылку на страницу с ответами. Но не сегодня. Чтоб интригу сохранить :)
Самое интересное, что сценарии для тестирования непосредственно на конкурсе смогут писать участники, то есть и ответы на все эти вопросы даст каждая команда сама для себя.
Я обязательно отвечу на них, скорее всего в Wiki, а тут обязательно оставлю ссылку на страницу с ответами. Но не сегодня. Чтоб интригу сохранить :)
Самое интересное, что сценарии для тестирования непосредственно на конкурсе смогут писать участники, то есть и ответы на все эти вопросы даст каждая команда сама для себя.
Можно подробнее про требования к поиску? Будет ли как-то учитываться качество поиска?
И еще, я думаю, все хотят знать метрики, по которым будет определяться победитель. Иначе ничего не понятно
Я сейчас соберу побольше фидбэка, которого уже достаточно вобщем-то, и внесу коррективы в страницу спецификации.
Метрика достаточно простая. Рассчитываться будет рейтинг каждой работы по некой формуле, штрафные баллы в которую будут начисляться за потраченные деньги в панели управления Скалакси (сколько проект потребляет ресурсов?), потраченные деньги в панели управления системой тестирования (сколько ресурсов ваша команда потратила для создания нагрузки на конкурента?) и количество некорректных ответов вашего приложения.
Время ответа мониторить смысла большого нет (поправьте, если мы неправы, мы рассмотрим ваши предложения), так как время ответа может ну очень сильно зависеть от выбора платформы.
Разве что кол-во запросов, на которые приложение отвечало > 20 секунд, считая 20 секунд некой психологической границей нормальной работы приложения.
Фактически, ваша задача на конкурсе сведется к тому, чтобы «выбить» из проекта конкурентов как можно больше ошибок, таймаутов, затрат на ресурсы, при этом недопустив слишком больших затрат со своей стороны.
Метрика достаточно простая. Рассчитываться будет рейтинг каждой работы по некой формуле, штрафные баллы в которую будут начисляться за потраченные деньги в панели управления Скалакси (сколько проект потребляет ресурсов?), потраченные деньги в панели управления системой тестирования (сколько ресурсов ваша команда потратила для создания нагрузки на конкурента?) и количество некорректных ответов вашего приложения.
Время ответа мониторить смысла большого нет (поправьте, если мы неправы, мы рассмотрим ваши предложения), так как время ответа может ну очень сильно зависеть от выбора платформы.
Разве что кол-во запросов, на которые приложение отвечало > 20 секунд, считая 20 секунд некой психологической границей нормальной работы приложения.
Фактически, ваша задача на конкурсе сведется к тому, чтобы «выбить» из проекта конкурентов как можно больше ошибок, таймаутов, затрат на ресурсы, при этом недопустив слишком больших затрат со своей стороны.
Т.е. верно я понимаю, что я пишу какой-то план тестирования(кстати, на чем?), который проходит моя система. Потом этим планом бьют конкурентов.
Вы не боитесь, что люди будут выбирать неадекватные планы, и точить свой проект под них?
Вы не боитесь, что люди будут выбирать неадекватные планы, и точить свой проект под них?
отсутствие критериев на эффективность работы самого приложения в плане скорости, честно говоря делают всю задачу не интересной — без этого требования все фактически сводится к тому что нужно сделать приложение:
1. работающее на небольших ресурсах
2. работающее правильно
фактически, если скорость ответа не будет участвовать в рейтинге можно сделать приложение которое будет на минимальных ресурсах отдавать один запрос в 5 секунд, отдавать его правильно, и при этом все требования будут выполнены
не весело :)
1. работающее на небольших ресурсах
2. работающее правильно
фактически, если скорость ответа не будет участвовать в рейтинге можно сделать приложение которое будет на минимальных ресурсах отдавать один запрос в 5 секунд, отдавать его правильно, и при этом все требования будут выполнены
не весело :)
Время отклика это абсолютно оправданный показатель. Сайтом с 0,5с никто не будет пользоваться.
А не-штрафные баллы как будут начисляться?
Время ответа имеет смысл мониторить, еще как! При этом, очевидно, на легкий запрос надо отвечать быстро.
Баллы будут сбрасываться после каждого этапа соревнования? По какой системе соревнование будет происходить? Олимпийская, круговая?
Время ответа имеет смысл мониторить, еще как! При этом, очевидно, на легкий запрос надо отвечать быстро.
Баллы будут сбрасываться после каждого этапа соревнования? По какой системе соревнование будет происходить? Олимпийская, круговая?
Ой, как интересно!
А тем, кто не сможет посетить HL, участвовать не получится, да? :(
А тем, кто не сможет посетить HL, участвовать не получится, да? :(
Согласен, было бы интересно поучаствовать, ещё можно было бы найти время по вечерам на разработку, но вот выделить 2 полных рабочих дня, чтобы приехать в Москву и поприсутствовать лично на конференции, малореально :)
Но идея вобще классная конечно, надеюсь организационные проблемы (с разными трактовками спецификации и нечеткостью правил) не подпортят картину.
Но идея вобще классная конечно, надеюсь организационные проблемы (с разными трактовками спецификации и нечеткостью правил) не подпортят картину.
Тут ситуация такая: у нас есть несколько свободных пригласительных на HL++, которые мы можем подарить тем, кто будет ну очень хотеть попасть на конференцию и будет участвовать в конкурсе. Так что если проблема в том, что вы не успеете купить билет — мы устроим какую-нибудь викторину в твиттере и поделимся с вами билетом.
На самом HL++ будет решающая часть конкурса, поэтому присутствовать все-таки надо.
На самом HL++ будет решающая часть конкурса, поэтому присутствовать все-таки надо.
Наша команда будет серьезно участвовать в соревновании, но т.к. мы студенты, то денег у нас на билеты нет. Так что если вы нам выдадите билетов, будет здорово, ну или по крайней мере на финальную часть пустите.
Жалко, меня не будет в Москве в эти даты :(
Есть желание участвовать, но вот возможности у всех приехать нет.
Возможен ли момент участия команды, но будет лишь её представитель присутствовать?
Возможен ли момент участия команды, но будет лишь её представитель присутствовать?
А есть какие нибудь ограничения на входные данные?
Скажем, если оппонент захочет запостить второй томик войны и мир и добавить туда 5к тегов.
Скажем, если оппонент захочет запостить второй томик войны и мир и добавить туда 5к тегов.
Хороший баттл, годный. Поучаствую.
Замечание по спецификации: дайте определение 'wildcards', желательно с примерами соответствия, типа
foo =~ foo*
food =~ foo*
foodcourt !~ foo*bar (если вспомнить DOS, то вовсе даже =~)
foo =~ fo?
fork !~ fo?
Замечание по спецификации: дайте определение 'wildcards', желательно с примерами соответствия, типа
foo =~ foo*
food =~ foo*
foodcourt !~ foo*bar (если вспомнить DOS, то вовсе даже =~)
foo =~ fo?
fork !~ fo?
Да, уже были просьбы по конкретике в плане поиска. Сделаю :)
И еще про поиск не понятно:
1. Производится поиск точного вхождения подстроки, или учитывается морфология? Т.е. если я ищу «машина», должны ли выводиться записи с подстрокой «мышины», «машине» и т.д.?
2. Регистр букв при поиске имеет значение?
То же самое и про теги… «Машина», «машина», «МАШИНА» — это один и тот же тег или разные?
Много в ТЗ недосказанного…
1. Производится поиск точного вхождения подстроки, или учитывается морфология? Т.е. если я ищу «машина», должны ли выводиться записи с подстрокой «мышины», «машине» и т.д.?
2. Регистр букв при поиске имеет значение?
То же самое и про теги… «Машина», «машина», «МАШИНА» — это один и тот же тег или разные?
Много в ТЗ недосказанного…
Если говорить про производительность, то, конечно, сложно будет соперничать программистам интерпретируемых языков с программистами С++.
Именно поэтому точное время каждого ответа приложения не будет непосредственно влиять на рейтинг. Но вот писать поиск на чистом C++ при большом объеме данных будет достаточно сложно. Задача поиска, задача подсчета кол-ва вхождений слов в статьи — они про алгоритмы. С плохим алгоритмом и на C++ будет не архибыстро.
Я подозреваю, что производительность подобного приложения упирается вовсе не в процессор.
Если, конечно, не наворачивать всякие там ORM и прочие фреймворки, тратящие 95% времени выполнения запроса на диспетчеризацию его к собственно полезному коду.
Если, конечно, не наворачивать всякие там ORM и прочие фреймворки, тратящие 95% времени выполнения запроса на диспетчеризацию его к собственно полезному коду.
Хорошо бы еще требования по сохранности данных
Если ничего не сохранять, то на все запросы можно честно отдавать пустые страницы.
Такой, знаете, дзенский блогодвижок получится. :)
Такой, знаете, дзенский блогодвижок получится. :)
Скажите, необходимо ли присутствовать на конференции лично или возможно удалённое участие?
Не совсем понятен вопрос с шириной канала, как для тестирования в процессе разработки, так и непосредственно на самой «битве». Ведь все может уперется в наличие мусорных сообщений (DOS) или объем трафика (допустим, пост в блог данных размером сотня-другая мегабайт. Десять постов хотя бы по 10Мб каждый… и страничку надо еще умудрится отдать целиком).
Собрал вопросы:
* Ограничен ли объём пост-запроса?
* Нужно ли корректно обрабатывать формат «multipart/form-data» или можно сразу 413-й код отдать?
* По спецификации нет корневого урла сайта — так должно быть или он должен существовать, но содержит произвольную информацию?
* После публикации на /post новой записи в блог должна быть выдана страница поста, редирект на список постов, сообщение об успешной публикации или произвольно?
* Как всё-таки должны обрабатываться символы подстановки (wildcards) в поисковых запросах?
* Когда можно будет понять, на какой именно платформе это будет крутиться и подумать, нахрена для этого API к Скалакси?
* Ограничен ли объём пост-запроса?
* Нужно ли корректно обрабатывать формат «multipart/form-data» или можно сразу 413-й код отдать?
* По спецификации нет корневого урла сайта — так должно быть или он должен существовать, но содержит произвольную информацию?
* После публикации на /post новой записи в блог должна быть выдана страница поста, редирект на список постов, сообщение об успешной публикации или произвольно?
* Как всё-таки должны обрабатываться символы подстановки (wildcards) в поисковых запросах?
* Когда можно будет понять, на какой именно платформе это будет крутиться и подумать, нахрена для этого API к Скалакси?
Я еще уточню про поиск, но все остальное — обновлено :)
Просмотрите, пожалуйста, статью.
Вы можете там зарегистрироваться и пообсуждать правила с нами.
Просмотрите, пожалуйста, статью.
Вы можете там зарегистрироваться и пообсуждать правила с нами.
Sign up to leave a comment.
Конкурс для разработчиков «HighLoad Battle»